simon

simon

github
HomeArchivesAbout

Domain Deployment Record: Starting from Receiving DMARC Reports

#DNS34
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
Recently, while managing the domain example.life, I received a DMARC report from Google indicating issues with emails claiming to be from my domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a standard that helps verify email authenticity, report results, and dictate handling policies for unauthenticated emails. Upon reviewing the domain's configuration, I found several issues, including unnecessary MX records, conflicting DMARC settings, and an empty DKIM record. Since I do not provide email services for this domain, I decided to delete the empty DKIM record to prevent errors and clean up the DNS configuration. The solution involved keeping DNS management with Cloudflare, removing all MX records, and retaining a strict SPF and DMARC configuration to enhance security. This cleanup maximized the domain's simplicity and trustworthiness while leveraging Cloudflare's features. I hope this experience helps others facing similar issues.

Recently, while managing an old domain example.life (real domain hidden), a small incident occurred: I received an email from Google regarding the DMARC report for the example.life domain.

These reports typically state: there are some emails claiming to be sent from your domain, but the actual sending server IP, settings, SPF/DKIM validations, etc., have either failed or are not configured.

What is DMARC?#

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a standard for email authentication, with three main functions:

  1. Validation: Tracks SPF/DKIM validation results to determine if the email genuinely comes from the specified domain;
  2. Reporting: Sends daily reports of the detection results to the specified email address;
  3. Processing Policy: Instructs the recipient on how to handle emails that fail validation (ignore, quarantine, or reject).

What are the risks of not configuring DMARC?#

  • Others can spoof emails from your domain, potentially being used for scams or spam.
  • Some sophisticated phishing emails can be hard to distinguish without validation, leading to business or credit losses.

Problem Analysis#

After receiving the DMARC report, I checked the existing configuration of example.life and found:

  • DNS is hosted on Cloudflare, not Namecheap.
  • MX records point to Namecheap's email forwarding service, but I no longer need email functionality;
  • SPF record is "disallow any sender," but there are also previous forwarding SPF settings;
  • DMARC records are duplicated, with one p=none and one p=reject, needing consolidation;
  • DKIM TXT record is empty, with no public key, making it meaningless.

Regarding the empty *_domainkey TXT record:

When generating DMARC configuration through the Email Record Creator in Cloudflare, an empty *_domainkey TXT record is also generated by default, but this record actually has no public key and does not handle DKIM validation, making it meaningless.

If I do not provide email sending services, it is best to delete this record directly:

  • Prevent email checking tools from reporting errors (soft alerts);
  • Keep the domain's DNS configuration cleaner.

If there is a personal email service, then the correct DKIM public key should be generated from the email service provider to complete the record.

In summary: Currently, example.life does not require email functionality, so directly deleting the empty DKIM TXT record is the best choice.

Solution#

  1. Ensure DNS remains hosted on Cloudflare, without switching back to Namecheap BasicDNS.
  2. Delete all MX records, no longer supporting any email functionality.
  3. Retain SPF TXT: 
    v=spf1 -all
    Indicating that my domain does not allow sending any emails.
  4. Retain DMARC TXT: 
    v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;
    Ensuring strict interception of any emails that fail validation.
  5. Delete the empty DKIM TXT record to ensure DNS cleanliness.
  6. Remove unnecessary _acme-challenge records (if no longer automatically maintaining certificates).
  7. Use Cloudflare's built-in DNS management interface for simple and efficient operations.

Conclusion#

Through this cleanup, the example.life domain has achieved a minimalist and maximized security posture:

  • No email services provided;
  • Complete prohibition of spoofing, maximizing the domain's trustworthiness;
  • Fully utilizing Cloudflare's protection, acceleration, and simple management capabilities.

Documenting this practical operation, I hope these experiences are helpful to you if you encounter similar issues.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.