Home / Commons / Email security check

Tool

Can someone send email as you?

Enter your domain and see, in plain words, whether the public records that stop people sending email in your name are in place, and how to fix the ones that are not.

FreeNo sign-upReads public DNS onlyAbout ten seconds

This tool needs JavaScript, which is turned off. Without it, you can check by hand: on a Mac or Linux computer open Terminal, on Windows open Command Prompt, and type nslookup -type=TXT _dmarc.example.org (with your own domain). The guides below explain what each record should say.

Free, no sign-up. This check only reads public DNS records. When you press Check, your browser sends the domain name, and any domains its SPF record points to, to Cloudflare’s public DNS resolver (privacy commitments). Nothing is sent to Moraph and nothing is stored.

Results

Enter a domain to see its records.

  • SPFNot checked yet
  • DMARCNot checked yet
  • DKIMNot checked yet
  • MTA-STSNot checked yet
  • TLS-RPTNot checked yet

Fix-it guide

What each record does, and how to fix it.

Do them in this order: SPF and DKIM for every service that sends as you, then DMARC in monitoring mode, then enforcement. MTA-STS and TLS reporting protect mail coming to you, and can be added at any time.

Your email platform’s own instructions come first: it knows its record values. Changes are made where your domain’s DNS is hosted, usually your domain registrar or web host. Google requires all senders to Gmail to use SPF or DKIM, and those sending more than 5,000 messages a day to also publish DMARC.

This is general information, not advice about your systems.

01 · SPF

Which servers may send as you

SPF (Sender Policy Framework) is a single TXT record on your domain listing the servers allowed to send email that uses your domain in the envelope (the hidden “return path” address). Receiving servers check it on every message.

How to fix it

  1. List every service that sends email as your domain. Your email platform, newsletter tool, donor or client database, website forms, finance and payroll systems. Ask each team; they often signed up on their own.
  2. Add each service the way it documents. Most give you an include: to add. Publish exactly one TXT record on the domain itself, starting v=spf1 and ending ~all or -all.
  3. Keep to one record. Two records starting v=spf1 is an error and receivers treat SPF as broken. Merge them into one.
  4. Stay within ten DNS lookups. Every include, a, mx, ptr, exists and redirect counts, including those inside the services you include. Over ten, SPF fails for every message. Remove services you no longer use; for a bulk sender, ask whether it can send from a subdomain such as news.yourdomain, which has its own record and its own limit.
  5. End with ~all or -all, never +all or ?all. Both ~all (“soft fail”: treat other servers as suspicious) and -all (“fail”) say that unlisted servers are not authorized. Once DMARC is enforcing, receivers act on DMARC and the difference matters less; the UK NCSC’s own examples use ~all. Move to -all only when you are sure every legitimate sender is listed. +all authorizes the whole internet.
  6. For a domain that never sends email, publish v=spf1 -all.

Example records

v=spf1 include:[your email provider’s SPF domain] ~allv=spf1 -all (a domain that sends no email)

02 · DKIM

A signature on every message

DKIM (DomainKeys Identified Mail) adds a digital signature to each message you send. The matching public key is published in DNS at [selector]._domainkey.[your domain]. Each sending service picks its own selector name, and selectors cannot be listed from outside, so this check only tries common ones. Not finding a key here does not mean DKIM is missing.

How to fix it

  1. Turn on DKIM signing in each sending service. Your email platform and most newsletter and database tools have a setting that gives you one or more DNS records to publish (often CNAME records). Publish them, then switch signing on.
  2. Use 2048-bit keys where the service allows. RFC 8301 requires RSA keys of at least 1024 bits and recommends 2048.
  3. Confirm it works. Send a message to a personal account at another provider, open the original message or full headers, and look for dkim=pass with d= your domain. That is the only reliable check from outside.
  4. Remove keys for services you no longer use, so an old key cannot be misused.

03 · DMARC

What receivers should do with fakes

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.[your domain]. It tells receivers what to do with a message that claims to be from your domain but fails both SPF and DKIM for it, and where to send reports. It is what actually stops someone sending email that shows your domain in the From line.

How to fix it

  1. Get SPF and DKIM right for every sender first. DMARC passes when either one passes for the domain in the From line.
  2. Start in monitoring mode with p=none and a rua= address for aggregate reports. Nothing is blocked yet; the reports show who is sending as you. They arrive as machine-readable files, so most organizations use a DMARC reporting service or tool to read them.
  3. Fix what the reports show. Add missing services to SPF, turn on DKIM where it is off. The current standard (RFC 9989) suggests at least a month at p=none.
  4. Move to p=quarantine, so failing mail goes to spam, and keep watching the reports for a similar period.
  5. Then decide on p=reject, which tells receivers to refuse failing mail. The UK NCSC calls reject on all your domains the best way to prevent spoofing. RFC 9989 warns that if your staff post to internet mailing lists, reject can cause their messages to bounce for other subscribers; quarantine is a reasonable place to stop in that case. A domain that sends no email at all can go straight to p=reject.
  6. Leave out pct=. RFC 9989 removed it because values other than 0 and 100 were applied inconsistently. Use sp= if subdomains need a different policy.

Example records

v=DMARC1; p=none; rua=mailto:dmarc-reports@[your domain] (monitoring)v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@[your domain]v=DMARC1; p=reject; rua=mailto:dmarc-reports@[your domain]

04 · MTA-STS

Encrypted delivery to you

Email between servers is usually encrypted, but an attacker on the network can sometimes force it back to plain text. MTA-STS (RFC 8461) lets you tell other servers to deliver to you only over an encrypted, verified connection. It has two parts: a TXT record at _mta-sts.[your domain], and a policy file at https://mta-sts.[your domain]/.well-known/mta-sts.txt. This check reads the record only; open the policy file in your browser to check it.

How to fix it

  1. Check your email platform’s instructions. The policy file must be served over HTTPS on the mta-sts subdomain, with a valid certificate.
  2. Start with mode: testing and set up TLS-RPT (below) so you hear about problems, then change to mode: enforce.
  3. Change the id= in the TXT record every time you change the policy file, so other servers fetch the new version.

Example records

_mta-sts TXT "v=STSv1; id=20261018"

05 · TLS-RPT

Reports when encryption fails

TLS reporting (RFC 8460) asks other mail servers to send you a daily report of any problems delivering to you securely. It costs nothing, changes nothing about delivery, and tells you if MTA-STS or your certificates are causing trouble.

How to fix it

  1. Publish a TXT record at _smtp._tls.[your domain] with an address that can receive the reports.

Example records

_smtp._tls TXT "v=TLSRPTv1; rua=mailto:tls-reports@[your domain]"

Sources

Where this comes from.

Primary sources only: standards bodies, governments, regulators and the services themselves. Each was opened and checked on 18 October 2026. If something here no longer matches the source, the source wins; please tell us at hello@moraph.org.

Last reviewed October 2026

  1. IETFRFC 7208: Sender Policy Framework (SPF)datatracker.ietf.org/doc/html/rfc7208
  2. IETFRFC 6376: DomainKeys Identified Mail (DKIM) Signaturesdatatracker.ietf.org/doc/html/rfc6376
  3. IETFRFC 8301: Cryptographic algorithm and key usage update to DKIMdatatracker.ietf.org/doc/html/rfc8301
  4. IETFRFC 9989: DMARC (May 2026, replaces RFC 7489)datatracker.ietf.org/doc/html/rfc9989
  5. IETFRFC 8461: SMTP MTA Strict Transport Security (MTA-STS)datatracker.ietf.org/doc/html/rfc8461
  6. IETFRFC 8460: SMTP TLS Reportingdatatracker.ietf.org/doc/html/rfc8460
  7. UK National Cyber Security CentreEmail security and anti-spoofingwww.ncsc.gov.uk/collection/email-security-and-anti-spoofing
  8. UK National Cyber Security CentreCreate and iterate an SPF recordwww.ncsc.gov.uk/collection/email-security-and-anti-spoofing/create-and-iterate-an-spf-record
  9. UK National Cyber Security CentreReject spoof emailswww.ncsc.gov.uk/collection/email-security-and-anti-spoofing/reject-spoof-emails
  10. GoogleEmail sender guidelinessupport.google.com/a/answer/81126
  11. Cloudflare1.1.1.1 public DNS resolver privacy commitmentsdevelopers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver
  12. CloudflareDNS over HTTPS: JSON formatdevelopers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json

Want help fixing what this found?

Shield helps eligible organizations put email authentication in place, alongside the rest of a security review. A person reads every application.

Apply for Shield