Skip to content

Fix DNS warnings #141

@tmhall99

Description

@tmhall99

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:

  1. In Cloudflare’s dashboard go to DNS → Add record
  2. 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=quarantine to p=reject once you’ve verified mail flow is clean.
      • Adjust rua/ruf addresses to wherever you want aggregate/forensic reports sent.
  3. 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=none to p=quarantine or p=reject via a _dmarc TXT 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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions