SPF
Pick the services that send your mail and we assemble a single, valid SPF record - warning you if it crosses the 10 DNS-lookup limit that quietly breaks SPF.

SPF and DMARC tell the world's mail servers who is allowed to send as you, and what to do with anyone who isn't. Build both records from plain-language choices, then copy and publish.
We'll publish these, read the reports, and ramp you to reject safely.
Used to address the DMARC host and, if you like, pull your current records to compare. The lookup runs in your browser using public DNS - nothing is sent to us.
Lists which services are allowed to send mail for your domain.
One mechanism per line - an include: your provider gives you, or an ip4: / ip6: for a server that sends directly.
v=spf1 include:spf.protection.outlook.com -all
Tells receivers what to do with mail that fails, and reports who is sending as you.
Aggregate (rua) reports - the most useful part of DMARC. A shared mailbox is fine; separate multiple addresses with a comma.
DMARCbis tag. Subdomains that don’t exist should never send mail, so reject is safe here even while your main policy ramps. Older receivers ignore it.
v=DMARC1; p=none
Hardfail (-all) is the strongest setting
-all tells receivers to reject mail from any server not listed above. Only publish this once you are sure every legitimate sender is included, or you will block your own mail.
Publish exactly one SPF record
A domain must have a single SPF TXT record. If you already publish one, merge these mechanisms into it - do not add a second v=spf1 record, as two records is an invalid configuration.
No aggregate-report address (rua)
Without a rua= address you get a policy but no visibility - you will never see who is sending as your domain or whether your own mail is aligning. Add an aggregate-report mailbox; this is the single most useful part of DMARC.
Monitoring mode (p=none)
p=none reports on abuse but does not stop it - failing mail is still delivered. This is the correct first step: collect reports for a few weeks, confirm all your legitimate senders align, then move to p=quarantine and ultimately p=reject.
DKIM keys are generated by each sending platform, not here - so there is no record for us to build. SPF and DMARC do nothing for DKIM alignment until you switch it on with your provider. Here is where to do that for the senders you picked.
Microsoft 365
Microsoft Defender portal (security.microsoft.com) - Email & collaboration - Policies & rules - Threat policies - DKIM. Enable DKIM for your domain; it publishes two CNAME records.
Want this set up and watched, not just generated?
We publish SPF, DKIM and DMARC for you, read the reports, and ramp the policy to reject safely - so your domain can't be spoofed and your mail still lands.
Pick the services that send your mail and we assemble a single, valid SPF record - warning you if it crosses the 10 DNS-lookup limit that quietly breaks SPF.
Choose a policy in plain English and get the DMARC record for _dmarc.yourdomain, with the recommended ramp from monitoring to full enforcement. Records follow DMARCbis, the updated spec: no deprecated pct tag, plus the new testing (t) and non-existent-subdomain (np) options.
DKIM keys come from each sending platform, so we point you to exactly where to switch it on for the senders you picked, rather than generating a record.
Not sure what you have today? Run the email deliverability audit to see your current SPF, DKIM and DMARC and where the gaps are. This generator builds the fix; the audit confirms it once you have published.
A monthly digest on email security, the Essential Eight, and practical hardening for Australian SMBs. No spam, unsubscribe anytime.