Frequently asked questions

DMARC Engine sets up and runs the email authentication for your domain so that mailbox providers can tell your real mail apart from anyone forging your address. We publish and host your DMARC, SPF and DKIM records, collect the aggregate reports that Gmail, Yahoo, Microsoft and others send back, and turn those reports into a clear picture of who is sending as you.

The end goal is enforcement: a policy of v=DMARC1; p=reject that tells the world to refuse mail that fails authentication. We get you there safely, without dropping your legitimate newsletters, invoices or helpdesk replies along the way.

No. You do not need to understand SPF syntax or DKIM keys. You add one delegation record at your DNS provider once, and from that point we manage the records for you. The dashboard explains what each report means in plain language, and an engineer reviews your account before any policy change.

If you do run your own DNS and prefer to keep control, that is fine too. We give you the exact records to publish and tell you when to change them.

Very little. We never need access to your mailboxes, your email server, or the content of any message. We need one thing: the ability to manage a small set of DNS records for your domain. Most customers delegate a subdomain to us with a single CNAME or NS record, which lets us host the authentication records without us touching the rest of your DNS zone.

If you would rather not delegate, you can copy the records we generate straight into your existing DNS panel. Either way, we only ever see authentication metadata, never your mail.

The initial set-up is usually 15 to 30 minutes of your time: create an account, add your domain, and publish one delegation record at your registrar or DNS host. After that, reports start arriving within a day or two as providers begin sending them.

Reaching full enforcement is a longer process, because we deliberately watch your live traffic for a few weeks first. See the enforcement questions below for how that timeline works.

Not if it is done properly. The danger with DMARC is publishing p=reject before every legitimate sending source is authenticated and aligned. If you skip that step, a service like your CRM, your invoicing tool, or a third-party helpdesk can suddenly have its mail rejected.

We avoid this by starting at p=none, which changes nothing about delivery, and only tightening the policy once the reports prove that every real sender passes. You move to enforcement when the data says it is safe, not before.

We use the reports as evidence. While you sit at p=none, every mailbox provider tells us which sources sent mail as your domain and whether each one passed SPF or DKIM with alignment. We work through that list until your payroll system, your marketing platform, your transactional sender and your own mail server are all green.

Then we tighten in stages: p=quarantine; pct= on a small percentage first, then up to full quarantine, then reject. At each stage the reports confirm nothing legitimate is failing before we move on.

For a typical organisation with a handful of sending services, expect three to six weeks from first report to p=reject. Domains with many third-party senders, regional offices or messy historical configurations take longer, because there is simply more to authenticate and verify.

We do not rush this. A domain that reaches reject in two weeks but bounces real invoices has failed. The reporting tells us the right moment, and we wait for it.

Yes, instantly. Because we host your DMARC record, loosening the policy is a single change that propagates with normal DNS speed. If an unexpected sender appears or a provider flags an issue, we can drop from reject back to quarantine or none in minutes while we investigate.

In practice this is rare, because the staged approach catches problems before they affect delivery. But the rollback is always there as a safety net.

The policy tag tells receivers what to do with mail that fails DMARC. p=none is monitor-only: nothing is blocked, but you still receive reports. p=quarantine sends failing mail to the spam or junk folder. p=reject refuses it outright, so a forged message never reaches the inbox at all.

Most domains that publish DMARC are stuck at p=none forever. They watch the reports but never block anything, which means they get the dashboards without the actual protection. The whole point of the work is to reach reject.

Alignment is the rule that makes DMARC stronger than SPF or DKIM on their own. It requires that the domain validated by SPF or DKIM matches the domain your recipients actually see in the From address. A message can pass SPF for some unrelated bounce domain, but if that domain does not align with From: accounts@yourcompany.com, DMARC still treats it as a failure.

This is what stops a spoofer. They might pass SPF for their own server, but they cannot make it align with your From domain, so a reject policy blocks them.

SPF is published as a TXT record starting with v=spf1. RFC 7208 sets a hard ceiling of 10 DNS lookups when evaluating it. Every include: for a service like Google Workspace, a marketing platform or a helpdesk counts towards that limit, and they nest. Cross the limit and SPF returns permerror, which means it fails entirely.

A record with 11 lookups returning permerror is one of the most common faults we see. Flattening resolves those nested includes down to the underlying IP ranges, so the record stays under 10 lookups. Our SPF flattening keeps the flattened record updated automatically when a provider changes its IPs.

DKIM adds a cryptographic signature in the DKIM-Signature header, and the matching public key is published in DNS at selector._domainkey.yourdomain.com, for example s1._domainkey.yourdomain.com. DKIM alignment means the signing domain in the d= tag matches the domain in your visible From address.

This matters because, unlike SPF, DKIM survives forwarding. A signed message that is forwarded still validates, so aligned DKIM is usually the more reliable of the two paths to a passing DMARC result.

Yes. MTA-STS forces inbound mail to your domain to use TLS, which closes off downgrade attacks on mail in transit. It works through a policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt plus a _mta-sts TXT record. We host both, so you do not need to stand up a separate web server for the policy.

We start in testing mode and pair it with TLS-RPT, a _smtp._tls TXT record that collects daily reports of any TLS failures. Once the reports are clean, we switch to enforce.

Yes, once you are enforcing DMARC. BIMI displays your brand logo next to your messages in supporting clients, currently Gmail, Apple Mail and Yahoo. It uses a _bimi TXT record with an l= tag pointing to your logo as an SVG Tiny PS file, and optionally an a= tag for a verification certificate.

The hard prerequisite is DMARC enforcement at p=quarantine or p=reject. BIMI will not show on a domain still at p=none, which is another reason reaching enforcement is the foundation for everything else.

It depends on the mailbox provider. A VMC, or Verified Mark Certificate, is issued by a certificate authority and requires a registered trademark for your logo. Gmail and Apple Mail expect a VMC (or its successor, a CMC) before they show the logo with the verified blue tick. Some clients display a logo from BIMI without one, but coverage is narrower.

If you do not yet hold a trademark, you can still publish the _bimi record and benefit where it is accepted, then add the VMC later. We will tell you exactly what each provider you care about requires.

Authentication is a large part of the picture, and for many senders it is the missing piece. If your mail is failing SPF, DKIM or DMARC, the bulk-sender rules at Gmail and the consumer Outlook services will push it to spam or reject it, and fixing authentication often produces a clear improvement.

Be realistic though: authentication is necessary, not sufficient. Reputation, list hygiene, spam complaint rates and content all still matter. We get the authentication and alignment correct, which removes the most common technical reason for filtering, but we cannot rescue a list full of stale or unhappy recipients.

The Google and Yahoo bulk-sender rules took effect on 1 February 2024. Bulk means roughly 5,000 or more messages a day to Gmail. They require SPF and DKIM, a DMARC record at p=none or stronger with alignment, one-click unsubscribe (RFC 8058) on marketing mail, valid forward and reverse DNS, and a spam complaint rate kept below 0.3% in Postmaster Tools.

Microsoft began applying similar expectations to high-volume senders (around 5,000 or more a day) to consumer Outlook.com, Hotmail and Live, announced in 2025. Mail that fails SPF, DKIM and DMARC is first routed to Junk, and the rollout moves towards outright rejection for non-compliant senders. Meeting all three providers at once comes down to the same foundation: aligned SPF and DKIM under an enforced DMARC policy.

Yes. PCI DSS 4.0 requirement 5.4.1 calls for anti-phishing mechanisms that protect personnel, and it became mandatory on 31 March 2025. DMARC is the recognised control for this, because it is what prevents attackers from sending phishing mail that appears to come from your own domain.

The same anti-spoofing question now turns up routinely in cyber-insurance applications and vendor security reviews. An enforced DMARC policy is a clean, evidenced answer to all of them, and the dashboard gives you the records and reports to show an assessor.

No, and any vendor who claims otherwise is overselling. DMARC stops exact-domain spoofing: messages that forge your real domain in the From address, for example a fake invoice claiming to come from accounts@yourcompany.com. At p=reject those are refused before they reach the inbox. This is the single most damaging class of impersonation, and DMARC is the only thing that closes it.

What DMARC cannot stop is lookalike domains. An attacker who registers yourc0mpany.com or yourcompany-support.com is sending from a domain they control, and they can authenticate it perfectly well. DMARC on your domain does nothing to those, so they need separate defences such as domain monitoring and user awareness. We are honest about that boundary.

There are two parts. Enforcement, the hands-on project that takes you from no protection to a safe p=reject policy, is a one-time fee of £200 as an introductory offer, normally £500. Monitoring, the ongoing reporting and managed hosting that keeps you there, is £19 per month introductory, normally £39.

Full current pricing is on the pricing section. If you want to see the state of your domain before paying anything, run a free check first with our scan tool.

Yes. You can add as many domains as you need under one account, including domains you own that should never send mail at all. Parked and inactive domains are a favourite target for spoofers, so we publish a strict reject policy on them straight away, since there is no legitimate traffic to protect.

Each active sending domain goes through its own enforcement journey, because each one has its own set of senders to authenticate and align.

Yes. If you manage email authentication on behalf of clients, we offer reseller and managed-service arrangements with consolidated billing and a single view across every client domain. Volume pricing applies once you are running more than a handful of domains.

Get in touch through the contact link on the site with a rough domain count and we will put together terms that fit how you operate.

No long-term contract. Monitoring is billed monthly and you can cancel at any time. Because we host your records, you are never locked in technically either: if you leave, we hand over the exact DMARC, SPF and DKIM records so you can publish them in your own DNS and keep your protection running.

The enforcement fee is a one-time charge for the set-up work, not a subscription, so there is nothing recurring tied to it. Ready to start? Create an account at app.dmarcengine.com/signup.