SPF and DMARC check

What the check verifies

An address in the From field does not prove who sent a message. SPF and DKIM help receivers authenticate the domains used to send and sign it. DMARC compares those domains with the domain in the From field and sets a policy for messages that fail authentication. This check reads public DNS records; it does not analyze sent messages.

• SPF lists the servers and services allowed to send email for your domain. We check the syntax, the number of records, how the record ends and the limit of 10 DNS lookups, including nested records.
• DMARC tells receivers what to do with a message that fails both SPF and DKIM: nothing (none), send it to spam (quarantine) or reject it (reject). We check the policy, the percentage it applies to, reporting and the parent domain's record.
• DKIM adds a digital signature to messages. Receivers verify it using a public key published in DNS. We look for the key at the selector you provide. If you leave it blank, we try common provider selectors. Not finding a key does not mean you do not use DKIM: your provider may use another selector. This check does not verify signatures on actual messages.

How to read the result

An enforcement result means the published DMARC policy requests quarantine or rejection for messages that fail aligned authentication. Receivers may apply local policy. DNS alone does not verify legitimate message signing or delivery. With p=none, DMARC requests monitoring only. DNS failures are shown as unverified.

your-company.com.         TXT  "v=spf1 include:spf.protection.outlook.com -all"
_dmarc.your-company.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@your-company.com"

How to roll out DMARC without losing email

1. 1

   List everything that sends email for you

   Besides your mail server, this often includes newsletters, a CRM, invoicing or a helpdesk. Each service must be in SPF or sign messages with DKIM using your domain.

2. 2

   Start with p=none and reports

   The record v=DMARC1; p=none; rua=mailto:dmarc@your-company.com blocks nothing but shows which servers send email for your domain. Reports are XML files, so a DMARC report analyzer helps to read them.

3. 3

   Fix the services that fail

   Add missing services to SPF or set up DKIM for them. Review the reports for at least a few weeks so that less frequent messages show up too.

4. 4

   Tighten the policy

   Move to p=quarantine and, after further checks, to p=reject. pct= allows a gradual move, but use it only temporarily.

Common SPF and DMARC mistakes

• Two SPF records: adding a new service creates a second record instead of updating the existing one. Receivers then treat SPF as an error.
• More than 10 DNS lookups: each service adds an include, and nested records add up. Remove unused services or use ip4 and ip6 ranges.
• DMARC left at p=none: monitoring is only the first step. Without quarantine or reject, spoofed messages still arrive.
• Unprotected subdomains: sp=none lets attackers send from made-up addresses such as invoices.your-company.com.
• Domains that send no email: they also need v=spf1 -all and v=DMARC1; p=reject, otherwise they are easy to abuse.

What the check cannot tell you

• It does not verify DKIM signatures on sent messages or whether receivers authenticate them successfully. A public DNS key alone does not prove it is being used. Also review DMARC reports and authentication results in the headers of delivered messages.
• It does not protect against lookalike domains such as your-cornpany.com. Employee training helps most against those.
• The result reflects DNS at the time of the check. Changes may take effect only after the record's TTL expires.
• The check reads only public DNS records, and we do not store the result.

Common questions