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).
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.
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:
The receiver should do what they would typically do without DMARC. Use none for all domains that want reporting without enforcement.
The message goes to the junk folder.
The message is rejected on an SMTP level, where it bounces back to the sender.
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.
By default, sending domains use the following record:
p= the policy.
ruf= 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.