-
Notifications
You must be signed in to change notification settings - Fork 27
Description
We ran a check against our website for mail deliverability concerns and this is ChatGPTs recommendations.
The tldr; is that only #1 can be mitigated, we can't do anything about #2-4 but they aren't big concerns.
1. DMARC “Quarantine/Reject policy not enabled”
Right now your DMARC record is almost certainly set to p=none, which only collects reports. To harden your domain against spoofing, switch to a quarantine or reject policy:
- In Cloudflare’s dashboard go to DNS → Add record
- Create a TXT record:
- Name:
_dmarc - Content:
v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@techforpalestine.org; ruf=mailto:postmaster@techforpalestine.org; fo=1- Change
p=quarantinetop=rejectonce you’ve verified mail flow is clean. - Adjust
rua/rufaddresses to wherever you want aggregate/forensic reports sent.
- Change
- Name:
- Save, then wait ~10 minutes for propagation.
Once in place, rerun your check—both the “dmarc” and “mx” warnings should clear.
2. SOA Serial Number Format is Invalid
Cloudflare auto‑manages your zone’s SOA record, including the serial. They don’t use the traditional YYYYMMDDnn format, so external checkers flag it. There’s no way to override this on Cloudflare’s free (or Pro) plans. If that checker is a hard requirement, you’d need to migrate your DNS to a provider that lets you hand‑edit the SOA. Otherwise, you can safely ignore this warning.
3. SOA Expire Value out of recommended range
Your zone’s Expire is set to Cloudflare’s default of 604 800 seconds (7 days). Some tools recommend an Expire between 14–28 days, but again Cloudflare doesn’t expose SOA parameters for editing. As with the serial format, you can only eliminate this warning by moving to a DNS host that allows custom SOA settings. In practice, a 7‑day Expire is quite common and won’t cause real‑world issues.
4. Reverse DNS does not match SMTP Banner (smtp.google.com)
This is coming from Google’s own outgoing mail servers. Google’s PTR records and SMTP banner don’t line up perfectly according to that checker, but you can’t change Google’s reverse‑DNS or HELO/EHLO banner. If you’re using Google Workspace for mail, you can safely ignore this—deliverability won’t suffer. Only if you run your own mail server would you need to:
- Set your PTR record (reverse‑DNS) on your sending IP to match
- Configure your SMTP banner (the hostname your server announces on connect) to that same name
—but none of that applies when you’re on smtp.google.com.
TL;DR
- Fix: DMARC → switch from
p=nonetop=quarantineorp=rejectvia a_dmarcTXT record. - Cosmetic/Cloudflare‑default: SOA serial & expire warnings—can’t change on Cloudflare; safe to ignore.
- Google‑specific: rDNS/banner mismatch for
smtp.google.com—unfixable (and harmless) when using Google Workspace.