Troubleshooting

21 June 2026 · 30 min read

Overview

This guide covers the problems admins most often hit while setting up or running DMARC Engine, and how to fix them - domains stuck in Pending, CNAMEs that won't resolve, DMARC reports that never arrive, SPF permerrors, DKIM alignment failures, MTA-STS stuck on "Activating", rejected BIMI logos, and forwarding that quietly breaks authentication. It also shows you how to use the built-in /lookup checker and the /audit log to work out what's actually wrong before you touch DNS again.

If you're setting a service up for the first time rather than debugging it, read the matching how-to guide first: DMARC setup, SPF setup, DKIM setup, MTA-STS setup and BIMI setup. This guide assumes you've already published (or tried to publish) records and something isn't working as expected.

Note DMARC Engine is a hosted platform. For every service, our recommended path is to delegate the record to us with a single CNAME and let us generate, sign and rotate the underlying content automatically. You can also self-manage by publishing the raw value yourself instead of the CNAME - most of the problems in this guide are specific to one path or the other, so we've flagged which applies as we go.

How hosted delegation works (the 30-second recap)

Every service in DMARC Engine follows the same pattern: you add one domain in Domains, the app gives you a hosting slug unique to that domain, and you publish a CNAME pointing at <slug>.<service>.dmarcengine.com. We serve the actual record content behind that CNAME and update it automatically when policy, SPF includes, DKIM keys or BIMI logos change - no further DNS edits required on your side.

Note SPF is the one exception to "just CNAME it" - the SPF spec doesn't allow a CNAME at the record apex the way DMARC/DKIM/BIMI do, so instead you publish a normal TXT record whose value includes our hosted SPF domain. We still do all the work: we flatten every include, a, mx and redirect mechanism behind <slug>.spf.dmarcengine.com down to raw IPs, so your published record never breaches the 10-DNS-lookup ceiling no matter how many services you use.

The alternative to any of the above is always available: publish the record's real value directly in your own DNS instead of the CNAME (self-managed mode). This guide calls that out explicitly wherever it changes the troubleshooting steps.

Quick diagnosis: where do I start?

Use this table to jump straight to the right section based on the symptom you're seeing.

Domain stuck in "Pending"

A domain (or an individual service on that domain) sits in Pending in Domains whenever we've issued you a hosting slug but haven't yet been able to confirm the matching CNAME exists in public DNS.

Step-by-step: diagnose a Pending domain

1. Open Domains and click into the affected domain to see per-service status (DMARC / SPF / DKIM / MTA-STS / BIMI each show their own state).
2. Note the exact hosting slug shown for that domain - it's case-sensitive and unique per domain, so don't reuse a slug copied from another domain or an old screenshot.
3. Open /lookup, enter the record name we expect (e.g. _dmarc.yourdomain.com), and run the check.
4. Compare the returned value against what the app told you to publish. Common mismatches: a trailing dot missing or extra, www. prepended by mistake, or the record published on the wrong subdomain (e.g. on mail.yourdomain.com instead of the apex).
5. If /lookup shows nothing at all, log in to your DNS provider and confirm the CNAME record actually saved - some registrars silently reject a CNAME at a name that already has other records (see the MX/CNAME coexistence note below).
6. If the record is present and correct, wait for propagation - most authoritative changes are visible within minutes, but some registrars cache for up to their configured TTL (commonly 300-3600 seconds). Re-run /lookup after the TTL has elapsed.
7. Still Pending after 24 hours with a confirmed-correct record? Check the Audit log for the domain - it records every verification attempt we made and why it failed, which is faster than guessing.
8. If the audit log shows repeated verification failures with no obvious DNS cause, contact support and include the domain name and the /lookup output from step 3.

Warning Pending is not the same as "broken" - mail flow is unaffected while a record is Pending, because until the CNAME resolves your domain simply has no DMARC/SPF/etc. record at all (or is still running whatever you had before). Don't remove your previous SPF/DMARC records until the new hosted ones show Active.

Tip If you manage many domains, sort the Domains list by status - Pending domains needing attention float to the top, so you don't have to click through each one.

CNAME not resolving

This is almost always one of five things: the record was never saved, it was saved at the wrong name, there's a conflicting record at the same name, a typo in the target, or the registrar's UI stripped something (like the trailing dot) that broke it.

Step-by-step: fix a non-resolving CNAME

1. Run the check publicly first, independent of our app, so you're not troubleshooting our cache instead of your DNS:

   dig CNAME _dmarc.yourdomain.com +short
   

1. If that returns nothing, log in to your DNS host and re-check the exact record type and name. A very common mistake is creating the record as _dmarc when your provider auto-appends the zone (giving _dmarc.yourdomain.com.yourdomain.com) - check the rendered/saved value, not just what you typed.
2. Confirm there isn't a pre-existing TXT record at _dmarc.yourdomain.com left over from a previous DMARC setup. A name cannot hold both a CNAME and any other record type (this is a DNS-protocol rule, not a DMARC Engine limitation) - delete the old TXT before the CNAME will resolve.
3. For DKIM, double check the selector matches exactly what's shown in DKIM for that domain - <selector>._domainkey.<domain> is selector-specific, so a typo'd or outdated selector (e.g. google vs google1) will simply return NXDOMAIN even though your DKIM setup elsewhere is fine.
4. For MTA-STS, remember there are two separate hosted CNAMEs (the policy host and the _mta-sts id/TXT host) plus TLS-RPT - check all three independently, since it's easy to publish one and forget the others:

   mta-sts.yourdomain.com.        CNAME  mta-sts.dmarcengine.com.
   _mta-sts.yourdomain.com.       CNAME  <slug>._mta-sts.dmarcengine.com.
   _smtp._tls.yourdomain.com.     CNAME  <slug>._smtp._tls.dmarcengine.com.
   

1. Once dig (or your provider's own DNS check tool) shows the correct target, re-run /lookup in the app - it checks from our resolvers directly and will flip the service to Active on its next scheduled poll, typically within a few minutes.
2. If dig from your own machine shows the record correctly but the app still won't verify it, that's a propagation/anycast quirk rather than a config error - give it one more TTL cycle before escalating.

; Example: correct DMARC delegation
_dmarc.example.com.  3600  IN  CNAME  acme7f2._dmarc.dmarcengine.com.

Note Some DNS panels (notably a few registrar-hosted ones) don't let you create a CNAME at a name starting with an underscore, or force you to omit the domain suffix in a confusing way. If your panel rejects the record outright, check its help docs for "underscore records" or switch that zone to a provider that supports RFC-standard host names (most do).

DMARC not showing aggregate reports

You've published _dmarc.<domain> and it shows Active, but Reports or Analytics still shows nothing, or shows far less volume than you'd expect.

Step-by-step: diagnose missing DMARC data

1. Confirm the record really is hosted and active in DMARC for the domain - a record can show green in Domains but you may be looking at Reports for the wrong domain if you manage several.
2. Check how long it's been. Aggregate (RUA) reports are sent by receiving mail servers on their schedule, usually once every 24 hours, and only after they've actually seen mail claiming to be from your domain. A brand-new domain with low mail volume can genuinely take 24-48 hours to show its first report.
3. Verify the record we're serving actually contains an rua= address pointing at your unique token, using /lookup:

   _dmarc.example.com.  IN  CNAME  acme7f2._dmarc.dmarcengine.com.
   ; resolves to:
   v=DMARC1; p=none; rua=mailto:r-9f13ac2e@reports.dmarcengine.com; ...
   

1. If you previously ran DMARC yourself or with another vendor, make sure you fully replaced the old _dmarc TXT record with our CNAME rather than adding ours alongside it - as noted above, two records at the same name is invalid DNS and most receivers will simply treat the domain as having no DMARC record at all, silently killing reports.
2. Check that mail is actually flowing for the domain in the first place - DMARC only reports on mail that was sent claiming your domain in the From: header. A domain used only for a handful of internal addresses may generate too little external mail volume for large receivers to bother reporting on.
3. Some large mailbox providers only send aggregate reports for domains crossing a minimum daily volume threshold, and some delay first reports for newly-observed domains by several days as a fraud-prevention measure - this is normal and not a DMARC Engine issue.
4. Check Audit for ingestion events - every RUA email we receive and parse is logged there. If reports are arriving but not appearing in Analytics, that's a processing issue worth reporting to support with the report timestamp from the sender's side if you have it.
5. Use the free DMARC record checker to confirm from a completely independent vantage point that the record resolves and parses as valid DMARC.

Warning If you run a mail-filtering or security gateway in front of your domain (e.g. a cloud email security product) that rewrites the return-path or wraps links, confirm it isn't also stripping or overriding your _dmarc DNS - some gateways offer their own DMARC "protection" mode that can conflict with a directly-hosted record.

Tip Don't wait for real-world mail to confirm your setup - send yourself a test message from the domain to an address at a large provider (Gmail, Outlook) and check the message headers for Authentication-Results to see an instant pass/fail on DKIM/SPF alignment, well before an aggregate report would arrive.

SPF too many lookups and PermError

SPF's own specification (RFC 7208) caps evaluators at 10 DNS lookups per check. Exceed it and receivers are required to return PermError, which typically causes them to treat the SPF check as a fail - this is the single most common SPF failure mode, especially once a domain uses several sending services (Google Workspace, a CRM, a marketing platform, a helpdesk...) each contributing their own include:.

Step-by-step: fix SPF PermError

1. Confirm which mode you're in. If you published our hosted include:

   yourdomain.com.  IN  TXT  "v=spf1 include:acme7f2.spf.dmarcengine.com ~all"
   

then lookups are already being flattened for you server-side - the visible record only costs you 1 lookup (the include itself) no matter how many senders you've added in SPF, because we resolve every nested include/a/mx/redirect down to raw IP ranges behind that hostname and republish it automatically when a sender changes their ranges.
2. If you're still seeing PermError with the hosted include published, the likely cause is a second SPF record, or a stray include: left over from before you migrated, sitting alongside ours. SPF only permits one TXT record starting v=spf1 per domain - a second one is invalid and receivers may reject or ignore both.
3. Check with /lookup:

   dig TXT yourdomain.com +short
   

and count how many strings start with v=spf1. If there's more than one, delete all but the hosted one.
4. If you're self-managing SPF (publishing the raw value yourself instead of our include), count your own lookups manually - every include, a, mx, exists and redirect costs one, and nested includes count recursively. Tools like the free SPF tools will do this count for you and flag the exact mechanism pushing you over.
5. The fix in self-managed mode is either to trim unused mechanisms, or to switch to the hosted include and let us flatten it - this is usually the faster fix since it also means future sender changes (e.g. your CRM rotating IP ranges) update automatically instead of silently breaking your flattened record again next quarter.
6. After changing anything, re-check with /lookup and also check a live message's headers for Received-SPF: to confirm pass rather than permerror or softfail.

; Hosted (recommended) - one lookup, auto-flattened
yourdomain.com.  IN  TXT  "v=spf1 include:acme7f2.spf.dmarcengine.com ~all"

; Self-managed alternative - you own the lookup budget
yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Warning Never publish two v=spf1 TXT records "just to add one more sender" - merge every include into a single record. Multiple SPF records is explicitly invalid per RFC 7208 and receivers are not required to average, prefer, or merge them; behaviour varies and is not something to rely on.

Note ~all (softfail) and -all (hard fail) both count toward alignment for DMARC purposes; the choice affects what receivers do with mail that fails SPF outright, not whether SPF passes for legitimate senders. Don't change all qualifiers as an SPF-PermError fix - it won't address a lookup-count problem.

DKIM failing or not aligning

DKIM failure shows up in DMARC aggregate reports as dkim=fail (the signature itself didn't validate) or as a pass with no alignment (the signature validated, but the signing domain d= doesn't match your From: domain the way DMARC's relaxed/strict alignment mode requires).

Step-by-step: diagnose DKIM failures

1. Open DKIM for the domain and confirm which selector(s) are active and hosted - you may have more than one selector if you use multiple sending platforms (e.g. one for Google Workspace, one for a marketing tool).
2. Check the CNAME resolves for that exact selector:

   dig CNAME selector1._domainkey.yourdomain.com +short
   ; expect: selector1.acme7f2._domainkey.dmarcengine.com.
   

1. If it resolves but a sending platform still reports DKIM failures, check that platform's own dashboard for the selector it's actually signing with - a common mistake is enabling DKIM signing in a third-party tool with a selector that doesn't match (or predates) the one hosted in DMARC Engine.
2. Distinguish signature failure from alignment failure by reading the raw Authentication-Results header on a real message, or the per-record detail in a DMARC aggregate report in Reports: dkim=fail means the signature itself broke (see step 5); dkim=pass with a d= domain that doesn't match your sending domain (in relaxed mode, the organisational domain) means it's an alignment problem, not a signing problem - the fix there is either changing DMARC's DKIM alignment mode or getting the sending platform to sign with your domain instead of its own.
3. Signature breakage in transit is usually caused by something rewriting the message body or headers after signing - mailing-list software adding a footer, a security gateway rewriting links, or a forwarder altering the Subject: or body. See Forwarding breaking DMARC below, since the root cause and fix are the same.
4. If you recently rotated or added a DKIM selector, remember both old and new selectors need to keep resolving until every queue of previously-sent-but-not-yet-delivered mail signed with the old key has been fully processed by receivers - don't delete an old selector's CNAME the same day you add a new one.
5. Re-test with a live message and check headers for dkim=pass and a matching aligned domain before considering it fixed.

; Hosted DKIM delegation for selector "s1"
s1._domainkey.yourdomain.com.  IN  CNAME  s1.acme7f2._domainkey.dmarcengine.com.

Tip If a single sending platform (say, your CRM) keeps failing DKIM while everything else passes, check the CRM's own DKIM settings first - it's far more often a mismatched selector or a "verify domain" step never completed on their side than a problem with the hosted record.

MTA-STS stuck Activating or certificate errors

MTA-STS enforces TLS for inbound mail to your domain, and it requires the policy file to be served over valid HTTPS, not just DNS. Because of that extra certificate step, MTA-STS is the service most likely to sit on "Activating…" longer than the others while a TLS certificate is issued for your custom hostname.

Step-by-step: fix a stuck MTA-STS activation

1. Confirm all three required records are published - MTA-STS needs the policy CNAME, the id/TXT CNAME, and (recommended) TLS-RPT:

   mta-sts.yourdomain.com.       CNAME  mta-sts.dmarcengine.com.
   _mta-sts.yourdomain.com.      CNAME  acme7f2._mta-sts.dmarcengine.com.
   _smtp._tls.yourdomain.com.    CNAME  acme7f2._smtp._tls.dmarcengine.com.
   

1. Check status in MTA-STS for the domain - "Activating…" specifically means DNS has verified but the HTTPS certificate for your custom mta-sts.yourdomain.com hostname hasn't finished issuing yet.
2. Certificate issuance requires the CNAME from step 1 to be resolvable and stable before it can be validated - if you added the CNAME and changed it again within the same hour (e.g. fixing a typo), the validation may need to restart from scratch. Give it a clean run after your last DNS edit.
3. Confirm nothing in front of your domain (a proxy, a firewall, a "DNS-only" vs "proxied" toggle at your DNS/CDN provider) is intercepting requests to mta-sts.yourdomain.com - the certificate issuance step needs to reach that hostname over plain HTTP for domain validation. If your DNS provider offers a proxy/CDN feature on CNAME records, make sure it's switched off (DNS-only) for the MTA-STS hostname.
4. If it's been Activating for more than a couple of hours with all records confirmed via /lookup, check Audit for certificate-validation attempts and errors logged against the domain.
5. Still stuck? This is one of the few cases worth contacting support proactively rather than waiting it out, since certificate issuance can occasionally need a manual retry on our side.
6. As a manual fallback while you wait (or if you prefer not to delegate this one), you can self-manage MTA-STS by hosting the policy file yourself on https://mta-sts.yourdomain.com/.well-known/mta-sts.txt and publishing the _mta-sts TXT value directly rather than as a CNAME - see the MTA-STS setup guide for the manual policy format.

Warning Don't remove the CNAME while it's "Activating" to "try again" - that resets the validation clock rather than speeding it up. Leave it in place and check back, or contact support if it's genuinely stuck rather than re-publishing it repeatedly.

BIMI logo rejected or not displaying

BIMI (Brand Indicators for Message Identification) shows your logo in supporting inboxes, but it has strict prerequisites: your DMARC policy must be enforcing (p=quarantine or p=reject, not p=none), your logo file must be a specific SVG profile, and some receivers additionally require a Verified Mark Certificate (VMC).

Step-by-step: fix a rejected or missing BIMI logo

1. Check your DMARC policy first in DMARC - BIMI is specified to require an enforcing policy (p=quarantine or p=reject) at a sufficient percentage; a domain still at p=none will not qualify at most receivers regardless of how correct the logo is. If you're still ramping up DMARC enforcement, see the ramp-up guidance in DMARC setup before troubleshooting BIMI further.
2. Confirm the logo format. BIMI requires SVG Tiny Portable/Secure (SVG Tiny P/S) specifically - not a general SVG export from a design tool. Regular SVGs commonly contain scripts, embedded raster images, or unsupported elements that BIMI validators reject outright.
3. Use the logo builder in BIMI to upload your source logo - we convert and validate it to SVG Tiny P/S automatically, so you don't need a separate converter; if a raster (PNG/JPG) source was uploaded, be aware it will be vector-traced and may need a manual touch-up if the automatic trace doesn't match your brand mark closely enough.
4. Check the CNAME resolves for your selector:

   dig CNAME default._bimi.yourdomain.com +short
   ; expect: default.acme7f2._bimi.dmarcengine.com.
   

1. If some receivers show the logo and others show a grey silhouette or your default avatar, that's expected and provider-specific - several major mailbox providers only display BIMI logos for domains holding a Verified Mark Certificate (VMC) from an approved authority, which is a paid trademark-verification product separate from DMARC Engine hosting. Check BIMI for whether a VMC is attached to the domain.
2. If you don't have (or don't need) a VMC, your logo will still display correctly at receivers that don't require one - don't treat partial display as a broken setup.
3. Re-verify with the free BIMI checker after any change, and allow a short caching window before providers pick up a freshly-fixed logo.

; Hosted BIMI delegation
default._bimi.yourdomain.com.  IN  CNAME  default.acme7f2._bimi.dmarcengine.com.

Note A VMC is not something DMARC Engine issues - it's a third-party certificate proving trademark ownership of your logo mark. We host and serve whichever logo (and VMC, if you have one) you upload, but the certificate purchase itself happens outside the platform.

Forwarding breaking DMARC

Mail forwarding - a .forward rule, a distribution list, a mailing list re-sender, or a "send a copy to" rule at a receiving mailbox - is one of the most common causes of intermittent DMARC failures, because forwarding frequently changes the very things SPF and DKIM depend on.

Why forwarding breaks authentication

• SPF validates the envelope sender (MAIL FROM), not the visible From: header. A classic forwarder resends your mail from its own server but keeps your original envelope sender - so the receiving server checks your SPF record against the forwarder's IP address, which was never authorised, and SPF fails.
• DKIM validates a cryptographic signature over specific header fields and the body. Anything that rewrites the Subject:, adds an unsubscribe footer, alters Reply-To:, or re-wraps links (common on mailing lists and some security gateways) invalidates the original signature.
• DMARC passes if either SPF or DKIM passes and is aligned - so forwarding alone doesn't automatically fail DMARC, but a forwarder that breaks both at once will.

Step-by-step: identify and mitigate forwarding-related failures

1. In Reports or Threats, look for a source IP range that consistently shows SPF failing but DKIM passing (or vice versa) for otherwise-legitimate mail - that pattern strongly suggests a forwarder rather than spoofing.
2. Cross-reference the reported source IP or hostname against known forwarding services your organisation uses - a mailing list host, a ticketing system that re-sends mail, or an individual employee's personal forwarding rule.
3. If DKIM is passing and aligned for that source, you're actually fine - DMARC only needs one of the two mechanisms to pass, so don't chase this further unless DMARC itself is failing.
4. If both SPF and DKIM fail for genuine forwarded mail, the standards-based mitigation is ARC (Authenticated Received Chain) - check whether the forwarding service supports signing an ARC header, which lets a DMARC-aware receiving server trust the forwarder's attestation that the original message passed authentication before being forwarded. Most large mailbox providers (Gmail, Outlook/Microsoft 365) both send and honour ARC.
5. If the forwarder doesn't support ARC and you control it, prefer ensuring it preserves DKIM signing intact (no body/header rewriting) - a passing, aligned DKIM signature survives most SPF-breaking forwarding scenarios cleanly.
6. Don't respond to isolated forwarding failures by loosening your DMARC policy back to p=none - that removes protection for every non-forwarded message too. Instead, ramp policy gradually per DMARC setup and monitor in Analytics whether the failing volume is meaningfully large before deciding it needs special handling.
7. If a specific known-good source is failing and you're confident it should be trusted, that's a conversation with the forwarding service's own support about ARC or DKIM preservation - it's not something DMARC Engine's records can fix from your side, since the forwarding server is a third party outside your DNS.

Note A rising SPF-fail/DKIM-pass pattern immediately after enabling a new mailing list or shared inbox tool is almost always this, not an attack - check Threats for the source before assuming compromise.

Using the /lookup checker to diagnose

/lookup is the fastest way to see exactly what's published in DNS right now, independent of the app's own cached status.

Step-by-step: get the most out of /lookup

1. Enter the exact record name you expect (e.g. _dmarc.yourdomain.com, s1._domainkey.yourdomain.com) - /lookup checks the specific name and type you give it, so a typo in the name you enter will look identical to a genuinely missing record.
2. Compare the CNAME target shown against the slug displayed for that domain in Domains - a stale slug (e.g. copied before you re-added the domain) is a common silent mismatch.
3. For SPF, use /lookup (or dig TXT) to confirm there is exactly one v=spf1 record and that it contains our include: if you're in hosted mode.
4. For DMARC and BIMI, /lookup will show you the fully-resolved record content (not just that the CNAME exists), so you can confirm the rua= address, policy (p=), or logo URL actually match what you expect without needing a separate dig.
5. Run /lookup again after any DNS change rather than assuming it worked - this is faster and more reliable than waiting for the Domains page status to refresh on its own polling cycle.
6. If /lookup and your own dig/registrar tool disagree, trust /lookup for what our resolvers see (which is what matters for hosted-service activation) and trust dig for what the wider internet sees (which is what matters for mail flow) - a brief mismatch between the two usually just means propagation is still in progress.

Using the /audit log to diagnose

/audit records every verification attempt, configuration change, and ingestion event for your domains - it's the fastest way to see why something failed rather than just that it failed.

Step-by-step: reading the audit log effectively

1. Filter by domain to cut noise if you manage several.
2. Look for verification-attempt entries around the time a service got stuck - these typically include the specific DNS response we received (or lack of one) at the time we checked.
3. For MTA-STS, look for certificate-issuance events specifically - these will show if a validation attempt failed due to an unreachable hostname or a proxy interfering with HTTP validation.
4. For DMARC, look for ingestion events showing which RUA emails were received and parsed - if you expect a report from a specific sender and don't see a matching ingestion event, the report likely never arrived (a sender-side issue) rather than being lost by us.
5. Cross-reference audit timestamps against your own DNS change history (most registrars keep one) to confirm you're looking at attempts made after your fix, not stale attempts from before it.
6. Anything you can't explain from the audit log alone is exactly the kind of detail worth pasting into a support request - see below.

Verify it worked

Once you've made a change, confirm it properly rather than assuming - each service has a quick, independent check.

1. DMARC: Run /lookup on _dmarc.yourdomain.com and confirm it resolves to v=DMARC1; p=...; rua=mailto:r-<yourtoken>@reports.dmarcengine.com. Status in Domains should read Active.
2. SPF: Run dig TXT yourdomain.com +short, confirm exactly one v=spf1 string, and send a test email to a Gmail or Outlook address - check the received message's Received-SPF:/Authentication-Results: header for pass.
3. DKIM: Send the same test email and check Authentication-Results: for dkim=pass with a d= value matching your sending domain.
4. MTA-STS: Check MTA-STS shows Active (not Activating), and optionally fetch the policy directly:

   curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt
   

1. BIMI: Check BIMI shows the logo preview rendering correctly, then send a test email to an account at a receiver known to support BIMI display and check whether the logo appears (allow for the VMC caveat above).
2. Overall: After a day or two, check Analytics for a rising pass-rate trend across all mechanisms - this is the most reliable long-term confirmation that everything is working together, since individual test emails only prove the path from you to one receiver.

Common problems and fixes

When and how to contact support

Most of the issues above resolve within one DNS propagation cycle once the underlying record is correct. Reach for Support when:

• A service has been stuck in Pending or Activating for more than 24 hours with a record you've confirmed is correct via /lookup and independent dig.
• Audit shows repeated verification failures you can't explain from your own DNS.
• DMARC reports have stopped arriving for a domain that was previously receiving them normally (a possible ingestion issue on our side, not just low mail volume).
• MTA-STS certificate issuance appears stuck rather than merely slow.
• You suspect a BIMI logo conversion issue (the auto-generated SVG doesn't visually match your source logo).

When you contact support, include: the domain name, which service is affected, the exact output of your last /lookup check, and roughly when you last changed the DNS record. That's usually enough for us to trace the exact verification attempt in our own logs without a back-and-forth.

FAQ

Do I have to use the hosted CNAME, or can I just publish the records myself?
Self-managing is always available for every service - publish the record's real value directly instead of the CNAME. The trade-off is that you then own ongoing maintenance yourself: SPF lookup-count creep as you add senders, DKIM key rotation, MTA-STS policy hosting and certificate renewal, and BIMI logo re-conversion if you change your brand mark. The hosted CNAME keeps all of that current automatically.

Why does /lookup show Active but mail is still failing authentication somewhere?
/lookup confirms the DNS record resolves correctly, which is necessary but not sufficient - mail can still fail if, for example, a sending platform is using a different selector than the one you've published, or a forwarder is rewriting the message in transit. Check the specific service section above for what else to look at.

How long does DNS propagation actually take?
Most authoritative nameservers reflect a change within minutes, but resolvers that already cached the old value (yours, your ISP's, or a receiver's) hold onto it until the record's TTL expires - commonly 5 minutes to an hour, occasionally longer if a previous record was set with a long TTL. If you just lowered a TTL to prepare for a change, remember the old TTL still governs how long the old value is cached elsewhere.

Can I run DMARC Engine's DMARC hosting alongside another vendor's SPF or DKIM?
Yes - the services are independent per record type. It's common to host DMARC and BIMI with us while keeping SPF/DKIM managed elsewhere, or any other combination, as long as each record type only has one authoritative source at a time (never two v=spf1 TXT records, never a CNAME and a TXT at the same DMARC name, and so on).

Why does my DMARC pass rate look worse right after I add BIMI or MTA-STS?
It shouldn't - BIMI and MTA-STS don't affect SPF/DKIM/DMARC evaluation at all; they're independent, additive protections (brand display and transport encryption respectively). If your pass rate genuinely drops at the same time, look for an unrelated coincidental cause, such as a new sending platform going live in the same window - check Analytics for which source IPs are newly failing.

Do I need a VMC to use BIMI at all?
No - a VMC is only required by some mailbox providers to display your logo; others display BIMI logos without one. You can host and use BIMI fully without a VMC and still get display at every provider that doesn't require it.

What's the fastest way to prove a fix worked without waiting for an aggregate report?
Send a live test email to an address at a major provider (Gmail, Outlook) and read the Authentication-Results: header on the received copy - it shows SPF/DKIM/DMARC pass-fail instantly, well before a 24-hour aggregate report would confirm the same thing.

Where can I check things without logging in, before I even have an account?
The free tools page includes independent DMARC, SPF, DKIM and BIMI record checkers you can run against any domain, including ones not yet onboarded to DMARC Engine.

I fixed the DNS but the app still shows the old status - is something broken?
Almost always just a polling/caching delay, not a bug - re-run /lookup, which checks live rather than relying on the last scheduled poll. If /lookup itself shows the correct new value but Domains still shows the old status after a reasonable wait, that's worth a support ticket.

---

Related guides: DMARC setup · SPF setup · DKIM setup · MTA-STS setup · BIMI setup