Free tool

Check your domain's SPF, DKIM and DMARC

Three records decide what a mail server does with your emails. Enter your domain: we read them from public DNS, show you what they contain, and tell you what it means.

The domain on its own, without www. An email address works too.

  • No sign-up
  • No email address
  • Nothing is stored

DNS readout for github.com

Read just now, as this page loaded. Nothing was stored.

SPFWho is allowed to send email on your behalf.

In place

What it says

An SPF record is published.

It ends with “~all”: servers not on the list still get through, but flagged as suspicious. This is the most common setting.

The record, as published

v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all

Location queriedTXT github.com

DKIMThe signature proving a message really comes from you.

In place

What it says

A DKIM key answers on selector “google”. Your messages can therefore be signed.

A DKIM selector is named by whoever sends your mail: unlike SPF and DMARC, it has no fixed location. Amazon SES, Postmark and HubSpot draw a random one per domain — no tool of this kind can see those. A DKIM that is not detected here is not proof of a missing DKIM.

The record, as published

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAj6T5sl/RwdSqGoYWaWaFbS2UAeyPrEmd0gogocmRfS441qwR8/0KB81Hw89P0l4YiFRrXYk7NVIGfyCRHAYYZUzCkGeOysI2EjgzLFhd/NEsbRzOEc/kWkK/RO6JFq/5lOn6M9AZw/ap9tds4JG9ApgNNdSpPxp9DmvpsOSgNMVflRxQFrk3kdS4RNAPKu/OPoA7dlR/A/pECryjRoYgENtDXzdnK70HgCekems6UDzxDj61cjyoKoXtEMF/QsaHEQ1Gjfv014rDJBsubk/kT5VqHkWHa/ia68Z5r228Ety/wFfQNjXTx/J7KGZ9GkZlKED659eiJcLnWcKDSiQlhwIDAQAB

Location queriedTXT google._domainkey.github.com

DMARCWhat you ask servers to do with an unauthenticated message.

In place

What it says

The policy is “p=quarantine”: you are asking for unauthenticated messages to be put in the spam folder.

Subdomains follow a separate policy: “sp=reject”.

An aggregate report address is declared (“rua”): someone receives the summary of what is being sent in your name.

The record, as published

v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

Location queriedTXT _dmarc.github.com

Read another domain

The three records, in plain English

They do different jobs, and one does not replace another. It is their combination that lets a server decide.

SPF

The list of authorised senders

A TXT record published at your domain root, listing the servers allowed to send on your behalf — yours, your business mailbox provider's, your email marketing tool's.

When a message shows up, the receiving server looks at where it actually came from and compares that to the list. The final mechanism — “-all”, “~all”, “?all” — says what to do with servers that are not on it.

DKIM

The message signature

Your sending service signs each message with a private key. The matching public key is published in your DNS, at a location whose name — the selector — is chosen by that service.

The receiving server verifies the signature. If it is valid, the message was not altered in transit and does come from a service you authorised.

DMARC

The instruction, and the report

A TXT record on “_dmarc.your-domain” that answers a question SPF and DKIM leave open: what do we do with a message that fails both?

It does a second thing, often forgotten: it collects reports. The address declared in “rua” receives a summary of everything sent in your name, including by servers you know nothing about.

The three DMARC policies

It is the value after “p=”. Publishing DMARC protects nothing until you have left the first row of this table.

PolicyWhat you ask forWhat it protects
p=noneChange nothing, but send me the reports.Nothing. It is an observation stance, meant to be temporary.
p=quarantinePut unauthenticated messages in the spam folder.Impersonation stops paying off: the message arrives, but in a folder nobody opens.
p=rejectRefuse unauthenticated messages.The message does not arrive at all. It is the only setting that truly closes the door.

Frequently asked questions

Do I need an account to use this tool?
No. No account, no email address, no form to fill in. You enter a domain, we read its public DNS and show the result. Nothing is stored.
Where does this information come from?
From public DNS, queried at the moment you load the page. These are exactly the records any mail server consults before accepting a message from your domain. You can check them yourself with the “dig” command.
My DKIM shows as not detected — is that bad?
Not necessarily. A DKIM selector has no fixed location: your sending service chooses its name. We try the most widespread selectors, and some services draw a random one per domain. A DKIM not detected here may well exist.
Why is there no overall score?
Because we would have to invent it. A DNS record contains nothing from which a deliverability score could be computed, and a number backed by no measurement only serves to impress. We would rather show what we read.
I have just published my records and they are not showing.
DNS takes time to propagate — from a few minutes to a few hours, depending on your host and the declared time to live. Wait, then read again.

What if your sending were authenticated from the start?

Plumail is a European email marketing tool. It gives you the exact values to publish for your domain, and checks that they answer before your first send.

Create a free account

No credit card.