ConfigCheckup
Free trial

Free tools

Free SPF, DKIM, DMARC and MTA-STS check.

See how well a domain is protected against spoofing and phishing: SPF, DKIM, DMARC and MTA-STS, checked from public DNS in seconds, with how to fix each in Microsoft 365. No sign-up.

What is checked.

  • SPF

    Lists the servers allowed to send mail for the domain.

  • DKIM

    Signs outgoing mail so it can be proven genuine and unaltered.

  • DMARC

    Tells receivers what to do with mail that fails the checks: the setting that actually stops spoofing.

  • MTA-STS

    Makes other mail servers use an encrypted connection when delivering to you.

@                      TXT     "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey   CNAME   <copied from the Defender portal>
selector2._domainkey   CNAME   <copied from the Defender portal>
; Publish p=none to start collecting reports, then move to p=quarantine, then p=reject.
_dmarc                 TXT     "v=DMARC1; p=none; rua=mailto:<reporting address>"
_mta-sts               TXT     "v=STSv1; id=<date>"

How ConfigCheckup handles data

These are 4 of the 195 checks ConfigCheckup runs. Connected to a tenant, it runs 14 email authentication checks and 28 Exchange Online and Defender for Office 365 checks, and the rest of Microsoft 365 from MFA and admin roles to devices and sharing, then writes the report in your brand.

What SPF, DKIM, DMARC and MTA-STS each do.

Four DNS records, each with its own job. SPF and DKIM prove where a message came from; DMARC tells receivers what to do when they cannot; MTA-STS protects mail on its way to you.

  • SPF

    What it does
    Lists the servers allowed to send mail for the domain. A receiving server checks the server that delivered the message against the list. It covers the envelope sender, the return address servers use, not the From address people see.
    Where it lives in DNS
    One TXT record on the domain itself, starting v=spf1

  • DKIM

    What it does
    Adds a signature to each outgoing message, checked against a public key in DNS. It shows the message was signed by a server holding the private key, and that the signed parts were not changed on the way. It usually survives forwarding, where SPF does not.
    Where it lives in DNS
    A key under a selector, at <selector>._domainkey. For Microsoft 365, two CNAME records, selector1 and selector2

  • DMARC

    What it does
    Tells receivers what to do with mail that fails: nothing (p=none), treat it as suspicious (p=quarantine) or refuse it (p=reject), and where to send reports. A message passes when SPF or DKIM passes for a domain that matches the From address.
    Where it lives in DNS
    One TXT record at _dmarc, starting v=DMARC1

  • MTA-STS

    What it does
    Tells other mail servers to deliver to you only over an encrypted connection, to the mail servers you list, with a valid certificate. It protects mail coming in, not mail going out. TLS reporting (RFC 8460) sends you reports on those connections, including any that failed.
    Where it lives in DNS
    A TXT record at _mta-sts, and a policy file served over HTTPS at mta-sts.<domain>

Set them up in Microsoft 365, in this order.

DMARC depends on SPF and DKIM, so they come first, and DMARC starts by only reporting, so you see every sender before anything is blocked.

Fixed for you, after you approve

With Automate

Connected to your tenant and your DNS host (Cloudflare, Azure DNS or Amazon Route 53), ConfigCheckup publishes SPF and DMARC, turns DKIM on and hosts the MTA-STS policy, each as a change you approve, with the previous records kept as the way back.

  1. List everything that sends as the domain

    Microsoft 365, and anything else that sends mail with your address on it: newsletters, ticketing and finance systems, websites, printers and scanners. Each one needs to pass SPF or DKIM before DMARC is enforced.

  2. Publish one SPF record

    A single TXT record such as v=spf1 include:spf.protection.outlook.com -all, with an include for each other service that sends as you. The Microsoft 365 admin centre shows the expected record under Settings, Domains. A domain that never sends mail gets v=spf1 -all.

    How to fix it in Microsoft 365

  3. Turn on DKIM signing

    In the Microsoft Defender portal, under Email authentication settings, DKIM: choose the domain, publish the two CNAME records it shows (selector1 and selector2), wait for them to appear in DNS, then turn signing on.

    How to fix it in Microsoft 365

  4. Publish DMARC at p=none, with reports

    A TXT record at _dmarc such as v=DMARC1; p=none; rua=mailto:<reporting address>. Nothing is blocked yet: read the aggregate reports for a few weeks and fix any genuine sender that fails.

    How to fix it in Microsoft 365

  5. Move DMARC to quarantine, then reject

    Once the reports show only genuine senders passing, move to p=quarantine, then p=reject. A domain that never sends mail can go straight to p=reject.

    How to fix it in Microsoft 365

  6. Add MTA-STS, starting in testing mode

    Host the policy file listing your Microsoft 365 mail servers in mode: testing, publish the _mta-sts record, and add TLS reporting. Move to mode: enforce once the reports are clean.

    How to fix it in Microsoft 365

  7. Then close the side door: Direct Send

    Exchange Online can accept unauthenticated mail sent straight to its servers using one of your own domains, which can look internal. Move printers and apps that send this way to an authenticated route, then reject Direct Send.

    How to fix it in Microsoft 365

Common mistakes.

  • Two SPF records on one domain

    The standard allows one. With two, SPF returns an error instead of a pass for every message, so merge them into a single record.

  • More than ten DNS lookups in SPF

    Each include, a, mx and redirect counts towards a limit of ten, including those inside an include. Past it, SPF returns an error instead of a pass for every message. Remove services that no longer send.

  • An SPF record that allows anyone

    A record ending in +all passes any server in the world, and ?all says nothing either way. End it in -all, or ~all with an enforced DMARC policy.

  • DKIM records published, but signing left off

    Until signing is turned on for your domain, Microsoft 365 signs with its own onmicrosoft.com domain, which does not match your From address, so DKIM cannot help your mail pass DMARC.

  • DMARC left at p=none for good

    p=none collects reports and protects nothing. It is a first step, not the end.

  • Jumping to p=reject before reading the reports

    A sender you forgot, such as a finance system or a newsletter, is then refused too. Start at p=none and move up once the reports are clean.

  • Parked domains left open

    A domain that never sends mail can still be used to fake it. Give it v=spf1 -all and a DMARC policy of p=reject.

  • MTA-STS enforced with the wrong mail servers

    In enforce mode, servers that honour MTA-STS will not deliver to a mail server the policy does not list. Test first, and update the policy when your mail servers change.

Questions about email authentication.

Is p=quarantine enough, or do I need p=reject?

Both enforce DMARC. p=quarantine asks receivers to treat failing mail as suspicious, usually by putting it in junk, so a spoofed message can still reach someone. p=reject asks them to refuse it outright. The CIS Microsoft 365 benchmark accepts quarantine; CISA’s SCuBA baseline asks for reject.

Should SPF end in -all or ~all?

-all asks receivers to fail mail from servers not on the list; ~all marks it as a soft fail. With DMARC enforced, ~all is common, because DMARC decides what happens to failing mail. CISA’s SCuBA baseline asks for -all whatever DMARC does.

Why does the check say no DKIM key was found when we sign our mail?

A DKIM key lives under a selector the sending service chooses, and DNS cannot list them. The check looks for Microsoft 365’s two selectors and other common ones, so a provider using its own selector can show as not found. Your provider can tell you its selector.

Does Microsoft 365 set these up for our own domain?

No. Microsoft looks after SPF and DKIM for the onmicrosoft.com domain every tenant is given. For your own domains you publish SPF, DMARC and MTA-STS at your DNS host, and turn DKIM signing on in the Defender portal.

Does this free check read our mail or connect to our tenant?

No. It reads public DNS only, the same records any mail server reads, so it works on any domain. It cannot see inside Microsoft 365: settings such as forwarding, Safe Links or Direct Send need the tenant itself.