What are SPF, DKIM and DMARC? An email authentication guide for administrators
SPF, DKIM and DMARC are three DNS records that verify that emails sent on behalf of a domain actually come from that domain's owner. SPF defines the authorized servers, DKIM confirms the email wasn't altered, and DMARC determines what happens to mail that fails the check. Set up together, they make your domain much harder to impersonate.
What is SPF and what does it do?
SPF (Sender Policy Framework) is a DNS TXT record that declares which servers may send mail on behalf of your domain. The receiving server looks at the IP address the incoming mail came from and checks whether that address is authorized in your SPF record.
SPF's limitation is this: it only verifies the sending server in the delivery chain; it doesn't on its own protect the "From" address the user sees on screen. SPF checks can also break when mail passes through a forwarding service. That's why SPF isn't sufficient on its own.
What is DKIM and what does it do?
DKIM (DomainKeys Identified Mail) is a digital signature added by the sending server to every outgoing email. The signature's verification key is published as a TXT record in your domain's DNS. The receiving server verifies the signature with that key; if the signature is valid, it confirms the mail wasn't altered in transit and belongs to the signing domain.
DKIM holds up better than SPF through forwarding, because the signature travels with the content of the mail. Rotating the key regularly and removing the old key from DNS is good practice.
What is DMARC, and how does it work together with SPF and DKIM?
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM results to the "From" domain the user sees. For an email to pass DMARC, at least one of the SPF or DKIM checks must pass, and the domain of the check that passed must align with the "From" domain.
A DMARC record does two more things. First, it tells the receiving server what to do with mail that fails the checks: p=none (monitor only), p=quarantine (send to spam) or p=reject (reject). Second, it asks receiving servers for aggregate reports; these reports show who has been trying to send mail on your behalf.
How do you tighten DMARC policy step by step?
- Take inventory. List every service that sends mail on behalf of your domain: corporate email, bulk-send tools, accounting software, the support system.
- Complete your SPF record. Add all of these services to your SPF record and set its terminal qualifier.
- Turn on DKIM. Enable DKIM signing for each sending service and add the keys to DNS.
p=noneand start with it. Publish your DMARC record together with a reporting address, and monitor the reports for a few weeks.- Close the gaps. If reports show a legitimate but failing send, fix that service's SPF or DKIM setup.
- Tighten gradually. Start with
p=quarantineand move top=rejectonce all legitimate traffic passes.
What do DMARC reports tell an administrator?
DMARC aggregate reports are XML files summarizing the sends that major mail providers have seen under your domain's name. They show which IP addresses tried to send mail on your behalf, how many passed SPF and DKIM, and how many were rejected.
For an administrator, reports serve two purposes: finding a legitimate but misconfigured service, and seeing whether your domain is being impersonated by others. Reports are hard to read in their raw form; setting up a way to aggregate and summarize them is what makes them actually usable.
What are MTA-STS and TLS-RPT?
MTA-STS is a policy that tells servers sending mail to your domain to deliver it only over an encrypted, verified connection. It protects against interception attacks that rely on encryption being silently disabled along the way. TLS-RPT declares the address where problems with encrypted delivery should be reported. Together they complement SPF, DKIM and DMARC.
What are the most common configuration mistakes?
- Publishing more than one SPF record; there should be a single SPF record per domain.
- Exceeding the allowed DNS lookup limit in the SPF record.
- Forgetting about a bulk-send tool or piece of software, and having DMARC reject its mail.
- Publishing DMARC straight to
p=rejectwithout first monitoring reports. - Leaving old, unused DKIM keys in DNS.
How are domains and subdomains that don't send mail protected?
Attackers often use domains the organization never sends mail from at all: an old domain bought for a campaign, or a domain used only for the website. If these domains have no SPF, DKIM or DMARC record, fake mail sent under their name won't be blocked on the recipient's end.
Two records are enough for a domain that doesn't send mail: an SPF record that authorizes no servers (v=spf1 -all) and a DMARC record with a p=reject policy. For subdomains, the sp tag in the DMARC record lets you define a different policy from the main domain.
How are authentication results read in an email?
The receiving server writes SPF, DKIM and DMARC results into the mail's header as an Authentication-Results line. In this line, each check shows a result such as pass, fail, softfail or none along with the domain the check was performed for.
Looking at this line in a suspicious email quickly shows whether the mail really came from the domain it claims to. But the header only verifies the domain; ornek.com.tr instead of ornek-tr.com a similar-looking domain like this can pass every check with its own records. That's why the domain name itself must also be examined when reading the results.
How does SmartMail set up and protect your domain?
The System Health screen in the DBLinx organization dashboard reads your existing DNS and prepares the MX, SPF, DKIM, DMARC, MTA-STS and TLS-RPT records your SmartMail domain needs, shows each gap individually, and lets you download the whole set as a zone file. It only deals with mail records; it doesn't touch your website's records. The MTA-STS policy address is set up on your behalf, along with its certificate, once the relevant record is added.
DMARC reports arrive at SmartMail's aggregator address, are opened automatically, converted into readable form, and archived under your domain's name. For incoming mail, SmartMail calculates the sender's SPF, DKIM, DMARC and PTR results itself and shows them alongside each message. Product-side details: SmartMail domain and DNS setup. Step-by-step walkthrough: Adding DNS records.