Remote SupportWhy This Matters
Without SPF, DKIM, and DMARC, anyone on the internet can send email that looks like it came from your domain. Invoice fraud, CEO spoofing, phishing staff, impersonating suppliers. All trivially done against an unprotected domain.
Google and Yahoo now require DMARC alignment for bulk senders. ACSC lists email authentication in the Essential Eight maturity model. Cyber insurers ask about DMARC in renewal questionnaires.
The goal
Reach p=reject on your primary sending domain, with 100 percent SPF and DKIM alignment, and DMARC reports monitored continuously.
SPF (Sender Policy Framework)
SPF is a DNS TXT record that lists which servers are authorised to send email for your domain. Receivers check whether the sending IP is in your SPF list. If not, the message fails SPF.
Example SPF record for a Microsoft 365 tenant with a marketing platform
v=spf1 include:spf.protection.outlook.com include:_spf.mailchimp.com -all
Key directives
- v=spf1 - version
- include: - import another domain's SPF
- ip4: / ip6: - allow specific IPs
- a / mx - allow host records
- -all - hard fail (recommended)
- ~all - soft fail (weak)
Rules to follow
- Only ONE SPF record per domain
- 10 DNS lookup limit (watch nested includes)
- End with -all, not ~all
- Do not list IPs for senders that also have SPF records (use include: instead)
DKIM (DomainKeys Identified Mail)
DKIM cryptographically signs each outbound message using a private key. The public key lives in DNS. Receivers verify the signature to confirm the message was not tampered with and was genuinely signed by your infrastructure.
Example DKIM record (selector1 for M365)
selector1._domainkey.example.com.au
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3...
- Microsoft 365: enable DKIM signing in Defender portal after publishing selector1 and selector2 CNAME records
- Google Workspace: generate a key in Admin Console, publish TXT record at google._domainkey
- Third-party senders (Mailchimp, HubSpot, SendGrid, Xero): each has its own DKIM setup. Publish their records too.
- Rotate keys annually where possible
- Use 2048-bit keys (never 1024-bit for new setups)
DMARC (Domain-based Message Authentication)
DMARC ties SPF and DKIM together with a published policy and a reporting channel. It tells receivers what to do when a message fails authentication, and sends you aggregate reports about every source sending mail as your domain.
Example DMARC record at _dmarc.example.com.au
v=DMARC1; p=reject; rua=mailto:dmarc@example.com.au; ruf=mailto:dmarc@example.com.au; fo=1; adkim=s; aspf=s;
p=none
Monitor only. Good starting point.
p=quarantine
Send failing mail to spam folder.
p=reject
Bounce failing mail. The goal.
Supporting tags:
- rua= aggregate report destination (daily XML reports)
- ruf= forensic report destination (per-failure)
- adkim=s strict DKIM alignment (recommended)
- aspf=s strict SPF alignment (recommended)
- pct=100 apply policy to what percentage of mail (start at 10 if nervous)
- sp= policy for subdomains
Use a DMARC reporting tool (Dmarcian, EasyDMARC, Valimail, Postmark) to parse XML reports into readable dashboards. Critical for diagnosing failures.
BIMI (Bonus Round)
Brand Indicators for Message Identification displays your logo next to authenticated emails in Gmail, Yahoo, and Apple Mail. Requires DMARC at p=quarantine or p=reject, a VMC certificate (Verified Mark Certificate, roughly AUD $2,000/yr), and a hosted SVG logo.
Nice-to-have for brand trust. Not essential. Only worthwhile after p=reject is stable.
Step-by-Step Rollout
Inventory all senders
List every service that sends mail as your domain. M365, Google, Mailchimp, HubSpot, Xero, support desks, CRM, marketing automation, transactional SMTP.
Publish correct SPF
Include every legitimate sender. End with -all. Validate under 10 lookups. Use tools like MXToolbox or dmarcian SPF surveyor.
Enable DKIM on every sender
M365, Google, and each third-party. Publish selector records. Verify signing works via mail-tester or GlockApps.
Publish DMARC at p=none
Set rua reporting. Do not set p=quarantine or p=reject yet. Monitor for at least 2 to 4 weeks.
Analyse reports
Identify any legitimate senders failing alignment. Fix each one (add to SPF, enable DKIM, or retire the source).
Move to p=quarantine
Start with pct=25 for a week, then pct=100. Keep watching reports.
Move to p=reject
Step up to reject once no legitimate sources are failing. Keep monitoring indefinitely.
Lock subdomains too
Set sp=reject on the top-level domain. Publish explicit DMARC on subdomains that send mail. Block the rest with a restrictive wildcard.
Safely Reaching p=reject
The risk of rushing to p=reject is blocking legitimate mail. Invoices, newsletters, automated alerts, and SaaS notifications all stop arriving. Here is how to de-risk.
- Always start at p=none and spend 2 to 4 weeks reviewing reports
- Use a DMARC reporting platform. Raw XML is unreadable.
- Identify every legitimate sender and confirm SPF + DKIM alignment for each
- Fix or retire every source showing consistent fails
- Step up gradually: p=none then p=quarantine pct=25 then pct=100 then p=reject
- Maintain the reporting address forever. New senders get added over time.
Common Mistakes
Multiple SPF records
Only one SPF TXT record per domain. Merge them.
Exceeding 10 DNS lookups in SPF
Nested includes can silently blow past the 10-lookup limit. Use SPF flattening tools if needed.
Jumping to p=reject on day one
Guaranteed way to block legitimate mail. Stage the rollout.
No DMARC reporting
Without reports you are flying blind. Always set rua=.
Forgetting subdomains
Attackers spoof hr.example.com even when example.com is locked down. Set sp=reject.
Ignoring parked domains
Owned but unused domains must also publish SPF -all and DMARC p=reject. Otherwise attackers use them.
Breaking mailing lists
Some mailing lists rewrite From headers and break DKIM. Use ARC-aware relays or educate staff.
Get to p=reject Safely
We configure SPF, DKIM, and DMARC, monitor reports, and move your domain to p=reject without breaking legitimate mail. Start with a free domain audit.