Successfully deliver email to Gmail
Modern websites have interactive components that store requests from site visitors, and often the site owner needs to be contacted when certain actions happen on their site. A common example of this is a contact form. When a site visitor submits the form the most common notification sent to a site owner is an email.
But since this email is being sent by a server that runs the site (or some other third party delivery service) the email being delivered to the site owner instantly is more suspect to email providers. Gmail is notorious for silently blocking or sending email to spam, and is therefore a good goal post to measure email delivery against.
In short, if your email gets delivered successfully to a site owner’s Gmail account, you’ve probably done it correctly.
An issue of trust and verification
What most people don’t understand about email is that anyone can send an email with any “from” address on it, just like you could a paper letter in an envelope or a post card. There is almost no security or verification in standard email. The answers to this problem are methods that allows Gmail to connect something in the email to the site that sent it.
SPF, DKIM and DMARC
Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) all rely on a similar set of tools, DNS text records and in the case of DKIM and DMARC, an encrypted message that directly links the email sent with the authorized sender.
SPF is the simplest system to setup, as you only need to edit the DNS settings for a domain. But by itself it is no longer considered enough verification to allow emails to go through. What it does is list IP addresses this domain allows to send email on its behalf. And when the receiving email server reads the email, it can look at the sending IP address in the email headers and compare them to the IP addresses listed in the SPF record. If they don’t match, then it is considered to be more likely spam, phishing attempt or some other form of illegitimate email.
In summary, SPF is a “are you the mailman?” style verification system.
Example SPF DNS text record:
"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
DKIM also requires DNS text records, but these text records hold a cryptographic key instead of plain text instructions. How it works is the sending server is setup with secret cryptographic keys that it uses to add a special signature to the email header. When the email with this signature is received at the destination server, that server can then use the public key stored in the DNS text records to test whether or not the signature is real or not. If the encrypted email signature does not pass this test, then the server can determine (with a higher accuracy than SPF) whether or not the email was delivered by the same people that control both the domain name settings (public encryption key) and the server settings (secret encryption key)
This is a simplified explanation of how DKIM works, but at its core it ensures that there is verifiable proof that the sending device owner is the same as the domain name owner.
In summary, DKIM is a “do I recognize this person’s handwriting and signature?” style of verification system.
Example DKIM DNS text record:
"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3 GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"
DMARC is also based on DNS text records, but combines the verification of SPF and DKIM into an actionable tool that reports on abuses, errors and failures. How it works is the receiving email server, after finding an error with and email that was supposedly sent by you, can look up in your DNS settings what to do with the bad email, deliver, quarantine or reject the email. DMARC also tells the receiving server if SPF, DKIM or both are being used by the sending server, which adds an extra layer of security and verification.
In summary, DMARC is the answer to the question “what do I do with this junk mail?” from people getting junk that looks like it’s from you. (but isn’t, of course)
Example DMARC DNS text record:
How do you set these up?
To setup SPF, you need the IP address of any/all servers that are going to be sending email on your behalf. Or the providers may offer your SPF records in their administration tools. Copy/paste the SPF record into a new TXT record in your DNS settings for your domain name. You can use an SPF record generator like this one to help:
To setup DKIM is a lot more complicated, and require the servers that deliver the email to have special software setup and that is also connected to the email delivery software and configured to sign emails. Each domain name needs to be configured with its own set of keys and DNS settings. Your service provider needs to generate these and provide the DNS key values and then the DNS settings on your domain name need to be updated using these values.
DMARC can be setup using a configuration tool like this (link below), and is similar to SPF, in that it’s only a DNS text record that you need to add to your domain name. DMARC’s work is done on the receiving end, so server that deliver email only do not need to manage DMARC.
This site warns users to be careful with your DMARC rules, and alter them slowly over time.
How do you verify it’s actually working?
The first step is to verify your settings are correct here:
The second step is to send test emails to a SPF/DKIM testing system like this one:
The last step is to send test emails to a Gmail account and then view the headers like this:
There will be SPF and DKIM sections displaying whether or not they passed.
Read more about these systems: