Email authentication verifies authenticity in two ways:
Confirms the source of the email is correct.
Checks that any content is the same as the sender intended, and nothing has changed.
We use three forms of email authentication: SPF, DKIM and DMARC. All of these protocols use the Domain Name System (DNS).
The SPF, DKIM and default DMARC records used by Dotdigital comply with the new Gmail and Yahoo authentication requirements which went into force on February 1 2024.
Sender Policy Framework (SPF)
The Sender Policy Framework (SPF) is an email authentication technique that mailbox providers use to prevent anyone other than you from sending messages on behalf of your domain name.
With SPF, you specify the IP addresses of the authorised mail servers allowed to send mail on behalf of your sending domain. However, if your sending domain is within Dotdigital, only the IP address of our mail servers are specified. You cannot add additional IP addresses because all emails sent with your account uses our specific mail servers.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail is an email security standard to ensure messages are not changed or tampered with while in transit between the sender and recipient.
DKIM uses public-key cryptography to sign the header and body of an email with a private key at the time of sending. Then when a mail server receives your email, it uses the public key – published to the domain's DNS – to verify that the source of the email is correct and that the body of the message hasn't changed during transit.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
Domain-based Message Authentication, Reporting & Conformance (DMARC) helps Internet Service Providers (ISPs) detect and block malicious email practices. With DMARC, the domain owner can specify how they want to handle emails that fail authentication using SPF and/or DKIM. DMARC also allows reporting for successful and failed messages on a daily total and single message level.
Single message reporting, known as forensic reporting, is not widely used because of data protection concerns.
DMARC policies
Three DMARC policies define what a receiver should do with an email that fails authentication. However, the DMARC policy is only a recommendation, and every mailbox provider decides whether to follow it or not. For example, Gmail honours the DMARC policy.
Three DMARC policies:
Policy | Definition | Type |
None | The receiver should do what they would typically do without DMARC. Use none for all domains that want reporting without enforcement. | Monitoring policy |
Quarantine | The message goes to the junk folder. | Enforcement policy |
Reject | The message is rejected on an SMTP level, where it bounces back to the sender. | Enforcement policy |
Enforcement policy risks
There is a risk with using an enforcement policy, like quarantine or reject, that forwarding and mailing lists are prone to break authentication, and legitimate emails might be quarantined or rejected. For marketing emails, this risk is low.
Using BIMI?
If you want to implement BIMI, you must use an enforcement level policy.
Authentication for custom from domains (CFAs)
We configure CFAs with DMARC by default and set the policy to `none`. All reporting is sent to our reporting address for DMARC reports.
If you'd like to change the policy or add additional reporting addresses, contact our support team for help.
By default, sending domains use the following record:
"v=DMARC1;p=none;rua=mailto:rua-report@example.com;ruf=mailto:ruf-report@example.com;fo=0;adkim=r;aspf=r;rf=afrf;pct=100;"
Key
p= the policy.ruaandruf= the reporting addresses.pct= percentage – allows a gradual increase in DMARC adoption.
Delegating a subdomain
If you deploy DMARC for your organisational domain and delegate a subdomain to Dotdigital, you must let us know to adapt to your policy. Subdomains inherit their DMARC settings from their parent, so when we set up a DMARC record, we must overwrite that.