Does BT (btinternet.com) honor DMARC policies?
Published 13 May 2025
Updated 11 Aug 2026
11 min read
Summarize with
Updated on 11 Aug 2026: We updated this guide for RFC 9989 and clarified how BT combines DMARC with local filtering decisions.
Yes, BT says it uses DMARC to block fake or suspicious email. The practical answer is narrower because BT does not publish a detailed enforcement matrix showing how every p=quarantine or p=reject failure is handled at btinternet.com.
BT's public sender guidance tells senders to publish SPF and use DKIM with DMARC. That confirms DMARC is part of BT's filtering. The caveat is that a DMARC policy expresses the domain owner's assessment, while final handling remains receiver-side. BT can reject, quarantine, place in spam, rate-limit, override, or accept a message after considering local signals.
Treat BT as a receiver that evaluates DMARC, but do not use a user complaint alone as proof that BT ignored policy. If BT users report spoofed mail using your domain, get the full original headers and determine whether the message reached the inbox, spam folder, or another user-visible folder.
The direct answer
BT says DMARC is used in its filtering. That does not mean every DMARC failure at btinternet.com receives the exact disposition requested by the sender domain.
- Yes: BT's sender guidance says it uses DMARC and asks senders to authenticate mail.
- Caveat: DMARC policy informs the receiver's decision, but it does not dictate final delivery.
- Evidence: Reported tests show BT has blocked some authentication failures while allowing other DMARC failures through.
- Action: Move clean sending domains to p=reject and monitor receiver-specific outcomes.
The biggest mistake is treating "honor DMARC" as a yes-or-no property. DMARC has three published policy values: p=none, p=quarantine, and p=reject. The receiver evaluates authentication and alignment alongside reputation, user rules, forwarding, filtering signals, and its own risk model.
The operational answer is that BT uses DMARC, but each incident still needs evidence. A recipient screenshot or forwarded complaint is not enough. Original headers, folder placement, an SMTP response, aggregate report data, and a controlled test can show what happened.
BT Help page showing email delivery best practices for senders.
What honor means in practice
When people ask whether BT honors DMARC, they usually mean one of four things. Each one needs a different test. A receiver can evaluate DMARC, send reports, reject some failures, and override the requested policy in other cases.
|
|
|
|---|---|---|
Does BT check DMARC? | BT guidance mentions DMARC. | Treat DMARC as active. |
Does BT reject? | SMTP 550 or report data. | Confirm failure cause. |
Does BT quarantine? | Folder placement and headers. | Check spam folder first. |
Did spoofing pass? | Full original headers. | Check authentication and alignment. |
Common meanings of DMARC policy handling at btinternet.com.
A p=quarantine policy does not mean the recipient never sees the message. It means the domain owner considers failing mail suspicious. The common visible result is placement outside the inbox, usually spam or junk. Users can still see and report those messages.
A p=reject policy says the domain owner considers DMARC failures a clear sign that use of the domain is invalid. BT can use that signal with content, reputation, routing, and user-specific data, then reject, quarantine, or override the requested handling.
What senders control
- Policy: The domain publishes none, quarantine, or reject.
- Authentication: SPF or DKIM must pass with alignment to the visible From domain.
- Reporting: RUA data can show how participating receivers evaluated mail.
What BT controls
- Disposition: BT decides whether to accept, junk, reject, or override.
- Filtering: BT combines DMARC with reputation and abuse signals.
- User state: Mailbox rules and spam-folder visibility affect reports.
What RFC 9989 changes
RFC 9989 became the current DMARC specification in May 2026 and replaced RFC 7489. Its receiver guidance makes the answer about BT more precise: p=reject is an important assessment from the domain owner, but it is not a standalone SMTP command.
RFC 9989 says a receiver must not reject a message solely because the sender publishes p=reject. The receiver must apply other knowledge and analysis. Without that additional evidence, it must treat the failing message as if the policy were p=quarantine.
- Sender meaning: p=reject says the domain owner considers failed use of the domain invalid.
- Receiver decision: BT still decides final handling using DMARC and its other filtering evidence.
- Override visibility: Participating receivers should report policy overrides and their reasons in aggregate data.
- Deployment change: The pct tag has been removed and the t tag now signals testing mode.
This does not make p=reject ineffective. It gives BT a clear domain-owner signal and supports enforcement when BT's other analysis agrees. It also explains why a DMARC failure can reach a spam folder without proving that BT failed to evaluate the record.
Evidence to collect before blaming BT
If a BT user reports spoofed mail, start with evidence. The same symptom can come from a DMARC failure being accepted, a quarantined message being visible in spam, a forwarded copy losing authentication, or a message that passed DKIM because an approved platform was abused.
Evidence quality for BT DMARC incidents
Use higher-quality evidence before deciding that a receiver ignored your policy.
Low confidence
Complaint only
A user says they received spam using your domain.
Better
Screenshot
A screenshot shows folder placement and visible sender details.
Strong
Headers
Original headers show SPF, DKIM, DMARC, and routing.
Best
Test case
A controlled test isolates the exact failure condition.
There is also an important distinction between inbound BT handling and BT's own outbound domain. A 2024 BT Community thread documents a btinternet.com sender hitting a destination-server rejection because the sending domain failed DMARC with a reject policy. That is evidence about BT's outbound authentication at that time, not proof of how BT handles inbound mail addressed to btinternet.com users.
If a third-party sending platform uses an @btinternet.com address in the visible From field, you cannot change BT's DMARC record to accommodate that sender. Use BT's authenticated sending route or a domain you control with correctly configured authentication.
- Headers: Ask the BT recipient for the full original headers, not a forwarded copy.
- Folder: Confirm whether the message was in the inbox, spam, trash, or a custom folder.
- Alignment: Compare the visible From domain with the SPF and DKIM authenticated domains.
- Source: Match the sending IP or DKIM selector to an approved or unapproved sender.
- Reports: Compare the incident with aggregate data in your DMARC monitoring workflow.
How to test your own domain
Before testing BT, validate your own DNS. A broken SPF record, missing DKIM signature, or alignment mismatch can make the result look like a BT problem when the sender setup is the real cause. RFC 9989 removes the pct tag and replaces pct=0 testing behavior with t=y.
Current DMARC policy examplesdns
_dmarc.example.com TXT ( "v=DMARC1; p=quarantine; t=y; " "rua=mailto:dmarc@example.com" ) _dmarc.example.com TXT ( "v=DMARC1; p=reject; " "rua=mailto:dmarc@example.com" )
Use Suped's DMARC checker to confirm that the record parses correctly before drawing conclusions from BT delivery. This prevents a syntax problem or obsolete tag from being misread as receiver behavior.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After DNS validation, run controlled tests with one variable at a time. Use an aligned SPF failure with aligned DKIM passing, an aligned DKIM failure with aligned SPF passing, a message where both authentication methods pass but neither domain aligns, and a message where both methods fail. The first two should still pass DMARC through the other aligned method.
Do not use a live spoofing campaign as a test source. Use controlled infrastructure, test domains, and consent from mailbox owners. Keep each test narrow enough to identify the exact authentication or alignment condition.
If a BT rejection mentions SPF best practice, do not count it as proof that DMARC caused the rejection. That response can identify an SPF or sender-authentication problem before DMARC policy becomes the main issue. A clean DMARC test separates authentication results from alignment and final disposition.
What to do if spoofed mail reaches BT users
If your domain is at p=quarantine and spoofed messages are visible to BT users, remove uncertainty in your own mail stream before moving eligible domains to p=reject. A visible message in spam is consistent with quarantine handling and is not proof of inbox delivery.
Do not force reject across every domain at once. Identify domains where all legitimate senders pass DMARC, stage policy safely, and keep aggregate reporting active after enforcement. For domains that do not send mail, reject is usually the right assessment once DNS is correct.
Staying at quarantine
- Visibility: Spoofed messages can remain visible in spam folders.
- Complaints: Users still report brand abuse after junk placement.
- Risk: Some receivers override or soften quarantine outcomes.
Moving to reject
- Signal: BT receives a clear assessment that DMARC-failing use is invalid.
- Outcome: BT can reject or quarantine when its other analysis supports enforcement.
- Control: Clean sources reduce the chance of legitimate mail failing DMARC.
Suped's product supports the operational work behind that move. It groups verified and unverified sources, detects authentication issues, and gives fix steps for SPF, DKIM, alignment, and DMARC policy. That helps determine whether a domain is ready for reject without breaking legitimate mail.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For domains with many senders, Hosted DMARC reduces change risk because policy staging can be managed without repeatedly editing raw DNS. Suped also keeps receiver reports, authentication issues, hosted policy controls, and multi-domain status in the same operational view.
When BT behavior still looks wrong
If full headers show a clean DMARC fail against a reject policy and the message still landed in a BT inbox, document the original headers, timestamp, recipient domain, sending IP, DKIM selector, visible From domain, published policy, and exact folder. Check aggregate data for a reported local-policy or mailing-list override where available.
A flowchart for investigating a BT DMARC complaint.
A BT 554 response saying a message looks like spam or has been reported as spam is a filtering decision, not evidence of a DMARC failure. Review the exact SMTP response and BT's sender guidance, then send the timestamp, sender domain, sending IP, recipient domain, and full bounce to postmaster@btinternet.com if the authenticated traffic still fails.
For a verified DMARC enforcement case, compare the evidence with aggregate data and broader spoofing reports. The related problem of receiver enforcement follows the same rule: the sender publishes an assessment policy, while the receiver makes the final handling decision.
A defensible sender posture has every legitimate source passing DMARC, reject published where safe, aggregate reporting active, and incident evidence preserved for the postmaster team.
Views from the trenches
Best practices
Collect full headers from BT recipients before deciding whether a DMARC policy was ignored.
Stage policy changes by source, then move clean sending domains to reject with evidence.
Separate authentication and alignment tests so each rejection has one known cause.
Common pitfalls
Assuming a user complaint means inbox delivery leads to weak conclusions about BT handling.
Treating an SPF-based 550 response as proof of DMARC rejection can hide the real issue.
Leaving a sending domain at quarantine lets some spoofed messages remain visible to users.
Expert tips
Compare BT results with aggregate reports before asking a sender to change infrastructure.
Use reject for domains with clean sources, but keep reporting active after the switch.
Check whether spam placement, forwarding, or local rules explain reported delivery first.
Marketer from Email Geeks says BT's public sender guidance says it uses DMARC, so authentication should be treated as part of its filtering.
2021-12-03 - Email Geeks
Marketer from Email Geeks says a complaint about spam using a brand domain does not prove inbox delivery because users often report spam-folder messages.
2021-12-03 - Email Geeks
How to interpret BT DMARC results
BT uses DMARC, but a sender's policy does not guarantee one visible outcome for every message. For p=quarantine, expect failing mail to be treated as suspicious and remain visible in spam in some cases. For p=reject, expect BT to treat the policy as a strong signal and combine it with other analysis before final disposition.
Keep authentication clean, publish reject when legitimate sources pass consistently, and monitor receiver-specific outcomes. Suped's product connects aggregate reports with source classification, authentication diagnostics, policy controls, alerts, and multi-domain management so teams can investigate BT results without treating every delivery complaint as a DMARC enforcement failure.
