middleamerica.com — Email Deliverability Fix

Date started: 2026-03-08 Client contact: Vijay (vijay@middleamerica.com) Status: Monitoring — all DNS records in place, DKIM enabled by Vijay, waiting to confirm signing works

Infrastructure

The Problem

Vijay unable to send email to Gmail addresses for 1–2 months. Bounce comes from "PPE Hosted Dispatch" (Microsoft's Proofpoint filter). Gmail started strictly enforcing DMARC in early 2024 — emails failing SPF and missing DKIM get rejected.

Root cause: nameservers were changed when the website was built, and email DNS records didn't get set up correctly for Microsoft 365 in Cloudflare.

What We Found

• MX record correctly pointed to Microsoft 365 (mail.protection.outlook.com) ✓
• SPF only authorized GoDaddy (secureserver.net) — Microsoft not listed ✗
• No DKIM record at all ✗
• DMARC set to p=none (monitor only, not enforcing)
• 9 stale Squarespace/NS1 DNS records orphaned from a canceled Squarespace account

What We Did (2026-03-08)

1. Deleted 9 stale records: - 4x squarespacedns.com NS records - 4x nsone.net NS records - 1x Squarespace domain-verification TXT record

2. Updated SPF record: - Old: v=spf1 include:secureserver.net -all - New: v=spf1 include:secureserver.net include:spf.protection.outlook.com -all

What We Did (2026-03-08, session 2)

3. Discovered M365 tenant: middleamerica.onmicrosoft.com (found via MX pattern + DNS enumeration)

4. Added DKIM CNAME records (standard M365 DKIM setup — no TXT key needed from client): - Initially pointed to middleamerica.onmicrosoft.com (guessed tenant) - Updated to correct targets from Vijay's M365 admin (GoDaddy-managed tenant NETORG17867297): - selector1._domainkey.middleamerica.com → selector1-middleamerica-com._domainkey.NETORG17867297.y-v1.dkim.mail.microsoft - selector2._domainkey.middleamerica.com → selector2-middleamerica-com._domainkey.NETORG17867297.y-v1.dkim.mail.microsoft

5. Added autodiscover CNAME (was missing — helps Outlook client setup): - autodiscover.middleamerica.com → autodiscover.outlook.com

6. GoDaddy confirmed they have no DNS access — all changes must go through Cloudflare (as expected).

What We Did (2026-03-08, session 3)

7. Updated DKIM CNAMEs to correct targets — Vijay provided the actual DKIM values from M365 admin (Exchange > DKIM > "Publish CNAMEs"). The GoDaddy-managed M365 uses org ID NETORG17867297, not middleamerica.onmicrosoft.com. Updated both records in Cloudflare via API.

8. Vijay enabled DKIM signing in M365 — He toggled it on in Exchange admin center.

9. Verified DKIM keys are live — Both selectors return RSA public keys: dig +short selector1._domainkey.middleamerica.com TXT → v=DKIM1; k=rsa; p=MIIBIjAN... dig +short selector2._domainkey.middleamerica.com TXT → v=DKIM1; k=rsa; p=MIIBIjAN...

10. Tightened DMARC from p=none to p=quarantine:

    • Old: v=DMARC1; p=none; rua=mailto:...@dmarc-reports.cloudflare.net
    • New: v=DMARC1; p=quarantine; rua=mailto:...@dmarc-reports.cloudflare.net

Current DNS State (verified 2026-03-08 ~11:45 PM CT)

Outstanding

• [ ] Confirm DKIM signing is working — Vijay's test email (11:35 PM 3/8) still showed "couldn't verify" warning in Gmail. Expected — Microsoft can take up to 1 hour to start signing after DKIM is enabled. Have him send another test in the morning.
• [ ] If still failing: Check raw email headers in Gmail (Show Original) for Authentication-Results header. Look for dkim=pass or dkim=fail. If dkim=fail, M365 may not be signing yet. If no DKIM header at all, M365 hasn't started signing.
• [ ] After confirmed working: Consider tightening DMARC further to p=reject (currently p=quarantine)

Quick Diagnostic Commands

# Verify all DNS records
dig +short middleamerica.com TXT | grep spf
dig +short selector1._domainkey.middleamerica.com TXT
dig +short selector2._domainkey.middleamerica.com TXT
dig +short _dmarc.middleamerica.com TXT
dig +short middleamerica.com MX

Billable Hours