Frequently Asked Questions

Find answers to common questions about DMARC, SPF, DKIM, and email authentication.

DMARC Forensic Reports (also known as Failure Reports or RUF reports) are rarely sent by email providers due to privacy concerns.

Most major providers like Google, Microsoft (Outlook/Office 365), Yahoo, and Apple do not send forensic reports at all. This is because forensic reports can contain sensitive information about individual email messages.

Why don't providers send Forensic Reports?

  • Privacy concerns: Forensic reports contain detailed information about individual emails.
  • Volume issues: Sending a forensic report for every failed email could overwhelm systems.
  • GDPR and data protection: Sharing email contents may conflict with data protection regulations.

The DMARC Aggregate (Summary) Reports provide sufficient information for monitoring and improving your email authentication.

We check for new reports every hour. However, please note that most email providers typically send their reports once a day.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that helps protect your domain from email spoofing. It allows domain owners to specify how unauthenticated emails should be handled and provides a way to receive reports about email sent from their domain.

To set up a DMARC record, add a TXT record to your domain's DNS settings. The record should include your DMARC policy ('none', 'quarantine', or 'reject') and an email address for reports. Example: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Yes, if you send in volume. Since February 2024 (Google & Yahoo) and May 2025 (Microsoft), anyone sending 5,000 or more messages per day to consumer inboxes must have:

  • Valid SPF and DKIM records
  • A valid DMARC record (at minimum p=none) with aligned authentication
  • A working one-click unsubscribe link in marketing mail
  • A spam complaint rate kept under 0.3%

Non-compliant mail is increasingly rejected outright. DMARC is now required for reliable delivery, not just a security best practice.

No. The pct tag (percentage-based rollout) is being removed in the updated DMARC standard (DMARCbis), and pct=100 was always the default. You can safely omit it and apply your policy in full. DMARCbis also adds an np tag to set a policy for non-existent subdomains — useful for blocking spoofing of unused subdomains.

  • SPF: Specifies which mail servers can send email for your domain.
  • DKIM: Uses cryptographic signatures to verify email authenticity.
  • DMARC: Builds on SPF and DKIM, specifying how to handle unauthenticated emails and providing reporting.

Without a DMARC policy, your domain is vulnerable to email spoofing, where malicious actors can send emails pretending to be from your domain. This can lead to phishing attacks and damage your domain's reputation.

SPF records start with v=spf1 and include mechanisms that define authorized servers:

  • ip4/ip6: Match specific IP addresses
  • a: Match the domain's A records
  • mx: Match the domain's MX records
  • include: Include another domain's SPF record
  • all: Match any IP (used at end)

Example: v=spf1 ip4:192.168.0.1 include:example.com -all

  • + (Pass): Default qualifier
  • - (Fail): Reject the email
  • ~ (SoftFail): Accept but mark suspicious
  • ? (Neutral): No action

  • Limit DNS lookups: SPF checks are limited to 10 DNS lookups.
  • Use -all carefully: Only when confident all senders are covered.
  • Keep it simple: Avoid overly complex records.
  • Monitor regularly: Review and adjust as your infrastructure changes.

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email was sent by an authorized mail server and hasn't been altered in transit. It protects your domain from spoofing and phishing attacks.

Yes, if you use multiple email service providers. Each provider generates a unique DKIM signature that needs to be added to your DNS settings.

  • d=: The signing domain
  • s=: The selector (locates public key in DNS)
  • h=: Header fields included in signature
  • bh=: Body hash
  • b=: The signature itself

  • Use strong keys: At least 2048-bit keys recommended.
  • Rotate keys regularly: Reduces risk of compromise.
  • Combine with SPF and DMARC: Comprehensive email authentication.

A DMARC Summary Report (Aggregate Report) provides an overview of email authentication results across your domain. It's generated daily by email receivers and includes data on pass/fail rates for DMARC, SPF, and DKIM checks.

Common reasons and solutions:

  • Incorrect configuration: Verify your DMARC record has correct rua email address.
  • Low email volume: Not enough email traffic to trigger reports.
  • Email filtering: Check spam/junk folders; whitelist report senders.
  • Report delays: Allow time for processing, especially during peak periods.

Include the rua tag in your DMARC DNS record. Example: v=DMARC1; p=none; rua=mailto:dmarc@example.com

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) tells other mail servers to require encrypted TLS when delivering mail to your domain, blocking downgrade and man-in-the-middle attacks. Where SPF/DKIM/DMARC authenticate who sent a message, MTA-STS protects the transport in between.

It is published in two places:

  • A DNS TXT record at _mta-sts.yourdomain.com — e.g. v=STSv1; id=20250101000000
  • A policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing your MX hosts and a mode (testing or enforce)

It is independent of DMARC but a good next step once your SPF, DKIM, and DMARC are in place.

TLS-RPT (SMTP TLS Reporting, RFC 8460) asks sending servers to send you a daily summary of TLS connection successes and failures when delivering to your domain. It is how you find out that MTA-STS (or DANE) is silently failing before it costs you mail.

Publish it as a DNS TXT record at _smtp._tls.yourdomain.com. Example: v=TLSRPTv1; rua=mailto:tlsrpt@example.com

It pairs naturally with MTA-STS.

BIMI (Brand Indicators for Message Identification) displays your brand logo next to authenticated messages in supporting inboxes such as Gmail, Apple Mail, and Yahoo.

BIMI requires DMARC at enforcement. Your DMARC policy must be p=quarantine (at 100%) or p=reject — a monitoring-only p=none policy will not qualify. The typical path is:

  • Get SPF and DKIM passing and aligned
  • Move your DMARC policy from p=none to p=quarantine or p=reject
  • Publish an SVG logo (SVG Tiny Portable/Secure profile) via a TXT record at default._bimi.yourdomain.com
  • For Gmail and Apple, obtain a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC) proving you own the trademark

Example: v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem