Changelog

Auditors and insurers ask the same questions in different words. The new Compliance page in the dashboard answers them from the DNS and mail facts yourDMARC already checks, with a citation for every control so you can see which clause a row comes from. It is evidence for your own review, not a certification.

Frameworks

• NIST SP 800-177 Rev. 1 (Trustworthy Email)
• PCI DSS 4.0.1
• ISO/IEC 27001:2022
• CISA Binding Operational Directive 18-01
• CCCS ITSP.40.065 (Canadian Centre for Cyber Security email guidance)
• Cyber-insurance questionnaires, the questions carriers most often ask about email
• Added 31 October: NIST SP 800-53 Rev. 5, the HIPAA Security Rule, CIS Critical Security Controls v8 and SOC 2 Trust Services Criteria

How it works

• Each control is marked met, gap or not checked for each domain, gaps first, with the evidence (the record or probe result) and what to change.
• A daily snapshot keeps the picture current, so a DS record published at your registrar today shows as met tomorrow.

DMARCbis (RFC 9989) replaces the original DMARC specification. It removes pct, ri and rf, adds np, t and psd, and finds the organisational domain by walking the DNS tree instead of using the Public Suffix List. Older records keep working, but some of what they say will be ignored.

The DMARC lookup now adds a DMARCbis readiness section to its results:

• Each finding is one line, marked OK, Change or Note.
• Removed tags are flagged, including what that means for you: a pct below 100 no longer samples, so use t=y for a staged rollout.
• An np value that leaves non-existent subdomains without enforcement is called out.

The classic add-domain page is replaced by a guided flow for new accounts:

1. Add domain. The domain is prefilled from your sign-up email; change it if you want to start somewhere else.
2. Review DNS. We scan the domain's live DNS and show any DMARC record it already has.
3. Add DMARC. Two tabs: "Host it for me (one CNAME)", which sets up Hosted DMARC so every later change happens in the app, or "Publish the TXT record myself", with the exact record to copy, our reporting address included.
4. Verify DNS. We check the record (or the CNAME) resolves and points reports at yourDMARC, with a plain explanation when DNS has not propagated yet.
5. Wait for reports. Mailbox providers send aggregate reports once a day, so the page shows the date to expect the first one and promises an email when it lands. While you wait, it links to the sender-requirements check, the spoofing test and the domain's DNS review.
6. Review senders. When the first reports are in, the dashboard shows who sends as your domain, who passes and what to fix first.

Dashboards you reach before any data exists now show an explanation and a next step instead of an empty chart, and an expired session returns you to the page you were on after you sign in again.

Look-alike monitoring (27 October) finds the names; the risk score says which ones matter today.

The score

• 0 to 100, with four levels: critical (70 and above), high (45+), medium (20+) and low.
• The reasons are listed with each score, so "critical" is never a black box.
• Inputs: whether the name can send or receive mail (MX, SPF, DMARC); how recently it was registered and with whom (a name held for three or more years scores lower); how recently it got a certificate, from the live Certificate Transparency feed; what its web page is (a live site, a site whose title uses your name, a parking page, or a redirect to your own domain, which lowers the score); and how confusable the name is, including Unicode look-alikes that render identically to yours.
• Existing look-alikes were scored on release day, and the weekly scan keeps the facts fresh.

Alerts

• When a look-alike becomes mail-ready or gets a certificate, the account is emailed. The subject opens with the level: "Urgent:", "High risk:", "Heads-up:" or "FYI:", and the in-app alert uses the critical icon for critical and high.
• From the dashboard, mark a name as ours or ignored once you know who owns it, and it stops alerting.

A perfect DMARC record on a domain whose DNS can be forged on the way to a receiver is not much of a defence. Over 27 to 29 October a new set of checks went live in the dashboard and in the free email spoofing test, under "DNS and mail-server hardening".

What is checked

• DNSSEC. Not enabled; enabled but not validating (mail to the domain bounces); signed at the DNS host but the DS record never published at the registrar; signatures about to lapse; deprecated signing algorithms.
• DANE. TLSA records that do not match the certificate the mail server presents; records that are unsigned, of a kind senders cannot use, or missing on some of your MX servers; and the cases where your provider already publishes DANE and only your own DNSSEC is missing.
• Null MX. A null MX next to real MX records, a null MX on a domain whose SPF still authorises senders, and domains that send and receive no mail but have no null MX.
• CAA. No CAA record at all, an unknown critical tag that blocks every renewal, an unreadable issuer, and a CAA set that leaves out the certificate authority your website actually uses.
• security.txt. Missing, expiring soon, or dated more than a year out.

Each finding says what is wrong, what it means for your mail and what to change, in plain language.

Alerts. Something that used to be right and has broken (DNSSEC no longer validating, a DANE mismatch) is emailed as an outage; a lapsing signature or an expiring security.txt arrives as a heads-up. Alerts only fire on a change from a known-good state, so turning the checks on does not flood you with history.

Since February 2024 everyone sending to Gmail or Yahoo Mail has to pass SPF or DKIM, have valid forward and reverse DNS, and keep spam complaints low; bulk senders also need both SPF and DKIM, a DMARC record, an aligned From domain and one-click unsubscribe in marketing mail. In May 2025 Microsoft brought Outlook.com, Hotmail and Live.com into line, and mail that fails is rejected.

DNS shows what you publish, not what your mail actually does, so the sender-requirements check grades a real message:

• Send one email from the system you want to check to the address the page gives you.
• When it arrives, we read the verdict Google's mail servers recorded on receipt and grade each rule: SPF, DKIM, DMARC alignment, one-click unsubscribe (RFC 8058), TLS and reverse DNS.
• Rules are grouped into "all senders" and "bulk senders", and the unsubscribe rules are marked marketing-only, so you can ignore them for receipts and password resets.
• Signed-in customers see the results for their domains in the dashboard too.

The provider rules side by side are on the sender requirements page; the requirement-by-requirement how-to is at /bulk-sender-requirements.

MTA-STS makes other mail servers use encrypted, verified connections when they deliver to you, so your inbound mail cannot be read or redirected in transit. Running it yourself means an HTTPS site with a valid certificate for mta-sts.yourdomain.com, a policy file, and the nerve to switch from testing to enforce. Hosted MTA-STS does all of that.

• Three CNAMEs, once. We build the policy from your MX records, show you what we would serve, and host the policy and its certificate.
• Testing first. Every domain starts in testing mode, where receivers report problems but still deliver.
• Automatic enforce (since 28 October). The domain moves to enforce after a clean week: enough TLS reports to judge, and no failures. The panel shows the evidence so far, and you can untick "Enforce automatically after a clean week" to decide by hand. A domain that gets too little mail to produce enough reports simply stays in testing, which is harmless.
• Steps back on its own. If failures appear after enforce, the policy drops back to testing automatically. You can also switch modes by hand at any time.
• Kept in sync. A nightly re-sync repairs the policy if your MX records change, and an hourly check watches the mail servers and the certificate.

Hosted MTA-STS sits beside Hosted DMARC on the domain page. It is included on paid plans, with an allowance of domains per plan.

Spoofing does not stop at your exact domain. A name one letter off, a different ending or a Unicode character that looks like a Latin one can carry a phishing campaign that DMARC on your own domain cannot touch.

What is watched

• For each of your domains, the look-alikes a phisher would reach for: swapped endings, missing or doubled letters, transposed letters, homoglyphs, hyphenated and prefixed forms, internationalised (IDN) spellings and bit-flip variants.
• Each registered look-alike shows whether it is mail-ready (it has mail servers, an SPF record or a DMARC record), registered but not set up for mail, or new since we started watching.
• Live Certificate Transparency watching: public certificate logs are read continuously, so a certificate issued for one of your look-alikes shows up minutes after issuance, usually before the site or the mail is live.

Where you see it

• Paid plans monitor every domain. The free plan shows a quick sample of the most common tricks.
• A Look-alike Domains page in the dashboard, and a panel on each domain's page.
• The free email spoofing test has a look-alike row for any domain.
• Mark a name as ours or ignored when you know who owns it.

Email alerts for newly mail-ready or newly certificated look-alikes follow with the risk score release.

BIMI shows your logo beside your messages in mailboxes that support it. It only works once DMARC is enforced, and the logo has to be a very specific kind of SVG served from a stable URL. Hosted BIMI takes care of both.

• Readiness first. The domain page says whether the domain is ready for BIMI and lists each check that still fails (an enforcing DMARC policy is the usual gap).
• Logo check before anything is stored. Pick the file in your browser; we check it meets the BIMI SVG profile and show you a preview.
• We host it. The logo is served from yourDMARC and the BIMI record is published for you, so there is nothing to keep online on your side.
• Certificates, explained. Yahoo and some others show a hosted logo on its own. Gmail and Apple Mail also need a Verified Mark Certificate (for a registered trademark) or a Common Mark Certificate (a logo in public use for at least 12 months). We do not sell certificates, but the panel explains which one fits and lets you ask us for help getting it issued.

Hosted BIMI is included in the Growth plan and above.

The email spoofing test grades a domain from 0 to 100 and answers three questions separately, because each has a different fix:

1. Spoofing your exact domain. Can a stranger send email as you@yourdomain today? No DMARC record, two records or p=none all mean yes, and the domain is graded F whatever else is right.
2. Mail that passes DMARC anyway. Are there holes in SPF or DKIM that let fake mail through? Partial protection (quarantine, pct below 100, weaker subdomain policies) and record problems lower the score from there.
3. Look-alike domains. Are names that look like yours registered and able to send email?

The fix list puts the most urgent change first and gives the exact record to publish where we can. The test works from the DNS you publish, so it is safe to run on any domain.

Hosted DMARC moves your DMARC record out of your DNS and into yourDMARC. You publish a single CNAME at _dmarc.yourdomain.com; we publish and serve the record it points to.

What changes for you

• Turn hosting on from the domain page. We read the record you publish today and copy it, adding our reporting address if it is missing. Your policy does not change at this point.
• We publish the record on our side first, then show you the one CNAME to add. Delete your existing _dmarc TXT record and add the CNAME; a CNAME cannot sit beside other records on the same name.
• Once the CNAME resolves, p=, sp=, np=, pct= and alignment (adkim, aspf) are settings in yourDMARC. Receivers see a change within minutes.
• Reporting addresses for another vendor are kept, so running two tools in parallel keeps working.

Safety

• Only valid records are hosted: one v=DMARC1, a valid p=, sp= and np=, pct between 0 and 100, long records split correctly.
• Every change is a history row: who changed what, when, from what to what, and why (a manual edit, a recommended step, autopilot or a re-sync). One click restores any earlier version.
• A daily job rewrites the published record if it drifts and checks that your CNAME still points at us.
• Turning it off is safe: replace the CNAME with a TXT record whenever you like. We keep serving your policy until you do, and the record is never deleted, because a domain with no DMARC record is spoofable.

Autopilot (opt-in) raises the policy one level at a time when the reports say it is safe, steps back if new failures appear, and emails you about every change.

Hosted DMARC is included on every plan. Read more on the Hosted DMARC page.