Email is one of the first areas Aramco's CCC auditors examine -- and one of the most common points of failure. The SACS-002 standard dedicates multiple controls specifically to email security, covering everything from the domain you send from to the authentication protocols configured on your mail server. If your company is still using @gmail.com or @yahoo.com for Aramco-related correspondence, this article will explain exactly why that fails the audit and what you need to implement instead.
The SACS-002 Email Controls at a Glance
Three TPC controls deal directly with email infrastructure, and two additional controls govern how email access is secured. Together, they form a comprehensive email security requirement that most vendors underestimate.
TPC-10 (Private Email Domain): All business communication with Aramco must originate from a private, company-owned email domain. Free email providers -- Gmail, Yahoo Mail, Outlook.com, ProtonMail free tier -- are explicitly prohibited.
TPC-10: The Private Email Domain Requirement
This is the most straightforward control and the one vendors most often violate. SACS-002 requires that every email address used for Aramco business communication belongs to a domain your company owns and controls. This means ahmed@yourcompany.com, not ahmed.yourcompany@gmail.com.
The rationale is simple: free email services do not give you control over authentication records, encryption policies, or account recovery. If an employee's Gmail account is compromised, your organization has no visibility or control over the breach. With a private domain, you control the DNS records, the mail server configuration, the account lifecycle, and the audit trail.
What counts as compliant:
- Email addresses on a domain you own (e.g.,
@yourcompany.comor@yourcompany.com.sa) - Hosted on a business email platform (self-hosted, Microsoft 365 Business, Google Workspace paid tier, or a managed email hosting provider)
- Domain registered in your company's name with registrar records available for audit
What does not count as compliant:
@gmail.com,@yahoo.com,@hotmail.com,@outlook.com(consumer free email)- Free-tier ProtonMail or Tutanota addresses
- Domains registered to third parties that you do not control
TPC-8: SPF Technology on Mail Server
TPC-8 requires that your mail server implements Sender Policy Framework (SPF) technology. This is a server-side configuration, not just a DNS record. Your mail server must be configured to check incoming emails against the sender's SPF record and to identify (and optionally reject) messages that fail SPF validation.
In practice, this means your mail server software -- whether Postfix, Microsoft Exchange, or a managed email platform -- must have SPF checking enabled. The auditor will ask for evidence that your mail server validates SPF on inbound messages, which typically requires a screenshot of the mail server configuration or a test email header showing SPF validation results.
TPC-9: SPF Record in DNS
TPC-9 requires that your domain's DNS zone contains a valid SPF record. This is the publishing side of SPF -- telling the world which mail servers are authorized to send email on behalf of your domain.
A proper SPF record looks like this:
v=spf1 include:mail.yourprovider.com -allThe critical detail is the -all qualifier (hard fail). A record ending in ~all (soft fail) or ?all (neutral) is technically weaker, and auditors may flag it. The -all directive tells receiving mail servers to reject any email that does not come from the servers listed in your SPF record.
TPC-2: Password Protection and MFA for Email Access
Email access falls under the broader access control requirements of TPC-2. For email specifically, this means:
- Email accounts must be password-protected with passwords meeting SACS-002 complexity requirements (8+ characters, special characters, 12-password history, 90-day rotation)
- If your email is cloud-based (Microsoft 365, Google Workspace, or any web-accessible email), MFA is mandatory
- Email access from mobile devices must also be authenticated and, for cloud email, MFA-enabled
For more details on SACS-002 password and MFA requirements, see our access control and MFA deep-dive.
Email TPC Control Mapping
The following table maps each email-related TPC control to its specific requirement and shows how a compliant email hosting package satisfies it.
| TPC Control | Requirement | Audit Evidence Needed | MassiveGRID Package Solution |
|---|---|---|---|
| TPC-10 | Private email domain for all business communication | Domain registration records, email address list showing company domain | Private domain email hosting included; domain registration assistance provided |
| TPC-9 | SPF record published in DNS for email domain | DNS query results showing valid SPF record with -all qualifier |
SPF record pre-configured in DNS during setup with hard fail (-all) |
| TPC-8 | SPF validation technology enabled on mail server | Mail server configuration screenshot or test email header showing SPF check | SPF checking enabled on inbound mail processing; test headers available on request |
| TPC-2 (Email) | Password protection meeting SACS-002 complexity on all email accounts | Password policy configuration screenshot from email admin panel | Password complexity, history, and rotation policies enforced at platform level |
| TPC-2 (MFA) | Multi-factor authentication for cloud-based email access | MFA enrollment evidence, login flow screenshot showing MFA prompt | MFA enabled by default for all email accounts; TOTP and hardware key support |
Why Free Email Fails the Audit: Specific Examples
To make this concrete, let us walk through exactly how a company using Gmail for business would fail the CCC audit:
Scenario: ABC Contractors uses ahmed@gmail.com
- TPC-10 violation:
@gmail.comis not a private company domain. The auditor flags this immediately. Even if the employee name is "Ahmed from ABC Contractors," the domain belongs to Google, not to ABC Contractors. - TPC-9 violation: ABC Contractors cannot publish an SPF record for
gmail.combecause they do not control that domain's DNS. No SPF record means no proof of authorized mail servers. - TPC-8 partial failure: Gmail does implement SPF checking on its servers, but ABC Contractors has no control over this configuration and cannot produce evidence of the server-side settings. The auditor needs to see your mail server configuration, not Google's.
- TPC-2 partial failure: Gmail supports MFA, but ABC Contractors has no way to enforce MFA across all employee Gmail accounts. Individual employees can disable it. The auditor needs evidence of mandatory MFA enforcement at the organizational level.
- Password policy failure: Gmail does not enforce 12-password history or 90-day rotation. These policies cannot be configured on consumer Gmail accounts.
The result: five control failures from a single decision to use free email. Each failure requires remediation before the certificate can be issued.
How SPF, DKIM, and DMARC Work Together
While SACS-002 explicitly calls out SPF in TPC-8 and TPC-9, a robust email security posture requires three complementary protocols. Understanding how they interact helps you appreciate why a properly configured email platform matters.
SPF (Sender Policy Framework)
SPF allows you to declare which mail servers are authorized to send email from your domain. When a receiving server gets an email claiming to be from @yourcompany.com, it checks your domain's SPF record in DNS. If the sending server is not listed, the email fails SPF validation.
SPF alone has limitations -- it only checks the envelope sender (the MAIL FROM address), not the header sender (the From: address visible to the recipient). This is why DKIM and DMARC are essential complements.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to every outgoing email. Your mail server signs each message with a private key, and the corresponding public key is published in your DNS. Receiving servers use the public key to verify that the message was not altered in transit and that it genuinely originated from your domain.
DKIM provides integrity (the message was not tampered with) and authenticity (the message came from your domain). It complements SPF by verifying the message content, not just the sending server's IP address.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. Your DMARC record specifies whether unauthenticated messages should be monitored (p=none), quarantined (p=quarantine), or rejected (p=reject). It also provides reporting, sending aggregate and forensic reports about authentication results to an address you specify.
A strong DMARC policy (p=reject) combined with valid SPF and DKIM records effectively prevents domain spoofing -- nobody can forge emails from your domain and have them delivered to recipients.
Best practice for CCC: While SACS-002 explicitly requires SPF, deploying DKIM and DMARC alongside SPF demonstrates defense in depth. Auditors view this favorably, and it protects your domain reputation with Aramco's mail systems.
What a Compliant Email Setup Looks Like
A CCC-compliant email environment has the following characteristics:
- Private domain: All email addresses use your company domain, registered in your company's name
- SPF record in DNS: A TXT record declaring authorized mail servers with a
-allhard fail directive - SPF validation on server: Inbound email checked against sender SPF records
- DKIM signing: All outbound email cryptographically signed; public key published in DNS
- DMARC policy: Published with at minimum
p=quarantine, ideallyp=reject - MFA enforced: All email accounts require multi-factor authentication at login; cannot be disabled by individual users
- Password policies enforced: Minimum 8 characters with special characters, 12-password history, 90-day maximum age, 10-attempt lockout
- Audit evidence available: DNS records exportable, mail server configuration documented, MFA enrollment reports accessible
MassiveGRID's Email Hosting: Pre-Configured for CCC
Setting up all of these components manually -- registering a domain, configuring a mail server, publishing DNS records, enabling MFA, enforcing password policies -- is a project in itself. For a small vendor preparing for CCC certification, it can consume weeks of effort and introduces risk at every configuration step.
MassiveGRID's CCC-compliant infrastructure package includes private email hosting with every email security control pre-configured from day one. SPF, DKIM, and DMARC records are published during setup. MFA is enabled by default. Password policies are enforced at the platform level, matching SACS-002 specifications exactly. And every configuration is documented with audit evidence ready for your assessor.
This means your team can focus on the business side of CCC compliance -- governance policies, risk assessments, employee training -- while the technical email controls are already in place and evidence-ready.
Get CCC-Compliant Email as Part of the Full Package
Email is just one component of SACS-002 compliance. The MassiveGRID Aramco CCC-Compliant Infrastructure Package bundles email hosting with managed firewall, VPN, encrypted file hosting, endpoint protection, and MFA-enforced remote desktop -- everything you need to pass the technical controls in a single deployment.