How to secure your email

Stop others from sending as your domain, make sure your own mail arrives, and keep the mailboxes behind it safe.

Anyone can put your domain in the From line of an email. Whether the receiving server believes it depends on a handful of DNS records that most domains set up once, half way, and never look at again. The result is phishing that looks like it came from you, and your own invoices and password resets landing in spam.

This journey sets those records up in the order that does not break your own mail. First you list every service that sends as your domain. Then you publish SPF and DKIM for each of them, turn DMARC on in monitoring mode, read the reports, and only then tell receivers to reject what fails. After that come the records that protect mail in transit (MTA-STS and TLS-RPT), your logo in the inbox (BIMI), and the parts DNS cannot fix: forms that must deliver, domains that should never send, and the mailboxes themselves.

Every DNS step has an auditor that reads the record for the domain of your monitored URL. A few steps complete by hand, because the right setup still leaves a warning for a while, or because nothing outside your mail provider can see them. Each of those steps says so.

Steps

Open a step to read it

1
List every service that sends as your domain
SPF, DKIM and DMARC all ask the same question: is this sender allowed to use your domain? You cannot answer it until you know who sends. Most domains have more senders than anyone remembers.
Do this
- Write down your mailbox provider (Google Workspace, Microsoft 365, Zoho, Proton, Fastmail)
- Add every service that sends on your behalf: newsletter tool, transactional email (Resend, SendGrid, Postmark, Amazon SES, Mailgun), CRM, helpdesk, billing, your web server's contact form
- For each, note the From address it uses and find its setup page for SPF and DKIM
- Ask finance, sales and support what they use. They often signed up for something on their own
Done when you have one list of senders with a setup page for each. Keep it: you will need it again in steps 3, 4 and 6.
2
Point MX at the server that receives your mail
Verifies with DNS Mail MX Auditor
MX records tell other servers where to deliver mail for your domain. Without them, replies to your newsletters, bounces and customer email have nowhere to go, and many receivers treat a domain with no MX as suspicious.
The DNS Mail MX Auditor looks up the MX records of the domain of your monitored URL. It fails when there are none.
Do this
- Copy the MX records from your mailbox provider's setup page, with the priorities it gives
- Remove MX records of providers you no longer use. Mail sent to an old provider is lost silently
- If the domain really receives no mail, publish a null MX (0 .) instead, as RFC 7505 describes, and handle it in step 11
Done when the auditor lists the MX hosts of your current provider.
3
Publish one SPF record that covers every sender
Verifies with DNS Mail SPF Auditor
SPF is a TXT record at the root of your domain that lists the servers allowed to send as it. Receivers check the sending server against that list.
The DNS Mail SPF Auditor fails when there is no SPF record or when there are two (receivers then ignore both). It warns when the record has no all at the end, when it ends in ?all or +all, which allow anyone, and when it is close to the 512-byte DNS limit.
Do this
- Build one record from the list in step 1, for example v=spf1 include:_spf.google.com include:amazonses.com ~all
- Merge any second v=spf1 record into the first and delete it
- End with ~all while you are still finding senders, and -all once DMARC reports show nothing legitimate failing
- Keep the record under 10 DNS lookups. Every include, a, mx and redirect counts, and receivers fail SPF above 10. Remove includes of services you no longer use
Done when the auditor passes.
4
Sign outgoing mail with DKIM
Verifies with DNS Mail DKIM Auditor
DKIM adds a signature to every message, made with a private key your sender holds. The matching public key is a TXT record at <selector>._domainkey.<your domain>. Unlike SPF, the signature survives forwarding, which is why DMARC relies on it most.
The DNS Mail DKIM Auditor looks for public keys under a list of common selectors (google, selector1, selector2, k1, s1, resend, sendgrid, mandrill, zoho and others). It fails when it finds none and when a key is malformed or empty, and warns on RSA keys shorter than 1024 bits.
Do this
- For each sender in step 1, turn on DKIM in its settings and publish the record it gives you (often a CNAME that points to the sender)
- Use 2048-bit RSA keys where the sender offers a choice
- Send a test message to a Gmail address and check "Show original": it should say DKIM: PASS with your domain
Done when every sender signs with your domain. The auditor can only find selectors on its list, so if your provider uses its own selector name the auditor may still fail after a correct setup. In that case check the test messages and mark the step complete by hand.
5
Turn on DMARC in monitoring mode
Verifies with DNS Mail DMARC Auditor
DMARC tells receivers what to do with mail that fails both SPF and DKIM for your domain, and where to send reports about it. Those reports are the only way to see who sends as your domain, you and everyone else.
The DNS Mail DMARC Auditor fails when _dmarc.<your domain> has no DMARC record. With p=none it warns: monitoring mode protects nobody yet.
Do this
- Publish a TXT record at _dmarc: v=DMARC1; p=none; rua=mailto:dmarc@your-domain
- Send the reports to a mailbox you read, or to a free or paid DMARC report service, which turns the XML files into something readable
- Wait at least two weeks so monthly senders, like billing, show up
Done when the record is live and reports arrive. The auditor keeps warning at p=none, which is expected at this stage, so this step completes by hand.
6
Read the reports, then enforce DMARC
Verifies with DNS Mail DMARC Auditor
The reports from step 5 list every server that sent mail as your domain and whether it passed. Some of those are your senders that you missed. Some are not yours.
The DNS Mail DMARC Auditor passes once the policy is quarantine or reject.
Do this
- For each source in the reports that is yours and fails, fix its SPF or DKIM and add it to the list from step 1
- When only unknown sources fail, change to p=quarantine. If you are cautious, add pct=25 and raise it over a few weeks
- Move to p=reject when quarantine has been quiet for a while
- Switch SPF to -all now (step 3)
- Keep reading the reports. A new tool someone signs up for will show up there first
Done when the auditor passes with quarantine or reject.
7
Require encrypted delivery with MTA-STS
Verifies with DNS Mail MTA-STS Auditor
Servers that deliver mail to you try to encrypt the connection, but by default they fall back to plain text if anything goes wrong, and an attacker on the path can make it go wrong. MTA-STS publishes a policy that says: only deliver to these MX hosts, and only over valid TLS.
The DNS Mail MTA-STS Auditor reads the _mta-sts TXT record and the policy at https://mta-sts.<your domain>/.well-known/mta-sts.txt. It fails on mode: none, and warns when the record is missing or malformed, when the policy cannot be fetched, and on mode: testing.
Do this
- Host the policy file on mta-sts.<your domain> over HTTPS with a valid certificate. Static hosting, a CDN or a worker is enough
- List every MX host from step 2 in it
- Publish _mta-sts with v=STSv1; id=<a value you change whenever the policy changes>
- Start with mode: testing, set up TLS-RPT (next step), and switch to mode: enforce when the reports are clean
Done when the auditor reports mode=enforce.
8
Get reports on delivery failures with TLS-RPT
Verifies with DNS Mail TLS-RPT Auditor
TLS-RPT asks the servers that deliver mail to you to send a daily report of connections that failed to encrypt. It is how you find out that MTA-STS, or your certificate, is rejecting real mail.
The DNS Mail TLS-RPT Auditor reads the TXT record at _smtp._tls.<your domain>. It warns when the record is missing, malformed or has no rua address.
Do this
- Publish v=TLSRPTv1; rua=mailto:tls-reports@your-domain
- Use the same report service as DMARC if it accepts TLS reports
Done when the auditor passes.
9
Show your logo with BIMI
Verifies with DNS Mail BIMI Auditor
BIMI puts your logo next to your messages in Gmail, Apple Mail, Yahoo and others. It is not a security control by itself, but receivers only show it when DMARC is enforced, so it rewards the work you just did and makes a spoofed message easier to spot.
The DNS Mail BIMI Auditor reads default._bimi.<your domain>. It warns when there is no record or when it is malformed.
Do this
- Make sure DMARC is at quarantine or reject (step 6)
- Make an SVG of your logo in the SVG Tiny PS profile and host it over HTTPS
- Publish v=BIMI1; l=https://your-domain/logo.svg
- Gmail and Apple also require a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC), which costs money and needs a registered or long-used logo. Add it with a= if you get one
Done when the record is live, or you decide BIMI is not worth it for you. BIMI is optional, so this step completes by hand.
10
Make sure your contact form delivers
Verifies with Contact Form
A contact form is mail you do not see sent. When SPF or DMARC tightens, the form's notifications are often the first thing to land in spam or bounce, because the web server or form plugin sends as your domain without being in SPF or signing with DKIM.
The Contact Form auditor fills in and submits a form on your site, then waits for the notification to reach 37 Audits. It is opt-in: on the URL's Configuration tab, set formPageUrl and formSelector, and forward the form's notification email from your inbox to contact-form-auditor@inbound.37audits.com.
Do this
- Send the form through one of the senders from step 1 (a transactional email service) instead of the web server's local mail
- Check that its From address passes SPF and DKIM
- Set up the auditor as described above and run it
Done when the auditor reports the notification arrived. If your site has no form, mark this step complete.
11
Lock down domains that never send
Attackers like domains that send no mail, because they usually have no SPF or DMARC and nothing will notice. That includes your parked domains, old brand names, typo domains you bought defensively and subdomains like app. or www..
The auditors in this journey check the domain of your monitored URL only, so this step completes by hand.
Do this
- For each domain that sends no mail, publish v=spf1 -all and v=DMARC1; p=reject
- Publish a null MX (0 .) on those that receive no mail either
- On your main domain, add sp=reject to DMARC once it is enforced, so subdomains without their own record are covered
- If you want to check one of these domains with the auditors above, add it as its own monitored URL
Done when every domain you own either passes steps 3 to 6 or rejects all mail.
12
Keep the mailboxes themselves safe
Records stop others from pretending to be you. They do nothing when someone signs in to a real mailbox. A taken-over mailbox sends perfectly authenticated phishing, and it is also where password resets for everything else arrive.
Nothing outside your mail provider can check this, so this step completes by hand.
Do this
- Require a second factor on every mailbox, and a phishing-resistant one (passkey or security key) for admins and finance
- Turn off legacy sign-in that skips the second factor: IMAP and POP with passwords, app passwords
- Review forwarding rules. Attackers add a rule that copies mail outside; block automatic forwarding to external addresses unless someone needs it
- Use role addresses (billing@, security@, dmarc@) owned by a group, not a person
- When someone leaves, close or convert their mailbox the same day
- Publish /.well-known/security.txt with a Contact: address so researchers can report problems to you
Done when every mailbox has a second factor and no unknown forwarding rules exist.
Related: How to secure your website.

Create an account, add your site as a monitored URL and work through these steps on it.