What is DMARC and do I need it?

Implementing DMARC (Domain-based Message Authentication, Reporting, and Conformance) is important for protecting your domain from email spoofing and phishing attacks. DMARC works in conjunction with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to ensure that email messages are properly authenticated.

Benefits of DMARC

  1. Prevents Email Spoofing: Ensures that only authorized senders can send emails on behalf of your domain.
  2. Improves Email Deliverability: Helps reduce the chances of your legitimate emails being marked as spam.
  3. Provides Reporting: Gives you visibility into who is sending emails on behalf of your domain, helping you monitor and take action against unauthorized senders.

Setting Up DMARC

  1. Ensure SPF and DKIM are Configured: Before setting up DMARC, make sure you have SPF and DKIM configured for your domain.

    • SPF: Add an SPF record to specify which mail servers are allowed to send emails for your domain.
    • DKIM: Configure DKIM to sign your emails with a private key, and publish the public key in a DNS record.

  2. Create a DMARC Record: Add a DMARC record to your DNS. This record will specify your DMARC policy, including how to handle emails that fail authentication checks and where to send reports.

Example DMARC Record

A basic DMARC record looks like this:

 

css

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; sp=none; aspf=r;

  • v=DMARC1: Specifies the version of DMARC.
  • p=none: Policy for emails that fail DMARC checks (none, quarantine, or reject).
  • rua: Aggregate report email address.
  • ruf: Forensic report email address.
  • sp=none: Subdomain policy.
  • aspf=r: Alignment mode for SPF (relaxed or strict).

Reading DMARC Reports

DMARC reports come in two types: aggregate reports (rua) and forensic reports (ruf).

  1. Aggregate Reports (rua):

    • Sent daily.
    • Provide a summary of all email authentication results.
    • Contain information such as sending IPs, email volume, and authentication results.
    • Can be read using tools like DMARC Analyzer, Dmarcian, or parsed manually.

  2. Forensic Reports (ruf):

    • Sent in near real-time.
    • Provide detailed information on individual emails that failed DMARC.
    • Contain headers and other metadata of the failing email.
    • Can be read using specialized tools or manually.

Tools to Simplify DMARC Implementation and Reporting

  • DMARC Analyzer: A platform to help you monitor and analyze your DMARC reports.
  • Dmarcian: Another tool that provides comprehensive DMARC management and reporting services.
  • Postmark, Agari, and Proofpoint: Offer DMARC services and tools for managing and reading reports.

Implementing and monitoring DMARC can significantly enhance your domain's email security and ensure better deliverability of your legitimate emails.

 

How do I read the DMARC email report sent to my inbox?

ChatGPT

Reading a DMARC report sent to your inbox involves interpreting XML files that contain the DMARC data. Here’s how you can read and understand these reports:

Steps to Read DMARC Reports

  1. Locate the DMARC Report:

    • DMARC reports are usually sent as email attachments in ZIP format.
    • Look for emails from various email service providers that send these reports (e.g., Google, Yahoo, Microsoft).

  2. Extract the ZIP File:

    • Save and unzip the file. Inside, you’ll find one or more XML files containing the DMARC data.

  3. Open the XML File:

    • You can open the XML file using a text editor (e.g., Notepad, TextEdit) or an XML viewer. However, reading raw XML can be cumbersome.

  4. Use a DMARC Report Analyzer:

    • For a more user-friendly approach, use a DMARC report analyzer tool to parse and visualize the data. Some popular tools include:
      • DMARC Analyzer
      • Dmarcian
      • Postmark
      • Agari

Manual Interpretation of the DMARC XML File

If you prefer to read the XML manually, here’s a basic guide to understanding the key elements:

  1. Metadata:

    • <report_metadata>: Contains information about the report, such as the organization that generated the report and the reporting period.
    • <org_name>: The name of the reporting organization.
    • <email>: The email address of the report sender.
    • <report_id>: A unique identifier for the report.
    • <date_range>: The time period the report covers.

  2. Policy Published:

    • <policy_published>: Describes the DMARC policy that was applied to the domain.
    • <domain>: The domain for which the policy is applied.
    • <adkim>: Alignment mode for DKIM (relaxed or strict).
    • <aspf>: Alignment mode for SPF (relaxed or strict).
    • <p>: DMARC policy for the domain (none, quarantine, or reject).
    • <sp>: Subdomain policy.
    • <pct>: Percentage of messages subjected to filtering.

  3. Record of Each Email Source:

    • <record>: Contains data for each source of email.
    • <row>: Describes the volume and disposition of messages.
      • <source_ip>: The IP address of the email sender.
      • <count>: The number of messages from this source.
      • <policy_evaluated>: The result of the DMARC evaluation.
        • <disposition>: The applied DMARC policy action (none, quarantine, or reject).
        • <dkim>: DKIM alignment result (pass or fail).
        • <spf>: SPF alignment result (pass or fail).

  4. Identifiers:

    • <identifiers>: Contains information about the email headers.
      • <header_from>: The domain found in the “From” header of the email.

  5. Auth Results:

    • <auth_results>: Describes the results of SPF and DKIM checks.
      • <dkim>: Details about DKIM authentication results.
      • <spf>: Details about SPF authentication results.

Example of DMARC XML

Here’s a simplified example of what a DMARC XML might look like:

 

xml

<feedback> <report_metadata> <org_name>example.com</org_name> <email>noreply-dmarc-support@example.com</email> <report_id>123456789</report_id> <date_range> <begin>1622505600</begin> <end>1622592000</end> </date_range> </report_metadata> <policy_published> <domain>example.com</domain> <adkim>r</adkim> <aspf>r</aspf> <p>none</p> <sp>none</sp> <pct>100</pct> </policy_published> <record> <row> <source_ip>192.0.2.1</source_ip> <count>10</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> <auth_results> <dkim> <domain>example.com</domain> <result>pass</result> </dkim> <spf> <domain>example.com</domain> <result>fail</result> </spf> </auth_results> </record> </feedback>

Using Tools for Analysis

  • DMARC Analyzer: Upload the XML files, and it will provide a detailed analysis and visualization of the data.
  • Dmarcian: Offers similar functionalities, with a focus on user-friendly dashboards and actionable insights.

By using these tools, you can save time and gain a clearer understanding of your DMARC reports.

 

Can I send Email from my University Domain?

Setting up 'From' addresses assumes that the domain has DNS records to authorise email to be sent, so it is unlikely that your University is prepared to add DNS records authorising CiviCRM for your institute or project.

  • e.g. Audienceware's domain is configured with DNS records authorising email to be sent via Amazon Web Services and Mandrill
  • even sending from a web server would require DNS records to be set up to authorise that server
  • these requirements are set by global conventions for spam protection and ensure trust

If you use your university email as your main email address, that assumes email is sent via the unversity's ESP (Email Service Provider), for which DNS would be set up to authorise.

  • we couldn't simply add that domain to Civi and expect email to be successfully delivered
  • e.g. if sent to someones's Gmail or Telstra email, those ESP's would lookup the DNS, see that it is not authorised, reject the email and report the sender

You could use another domain which could be used to send mail from CiviCRM

  • for sending, DNS could be setup to allow any SMTP service
  • for receiving, viable options are to either access to that email, inbound to Civi or some simple forwarding rules could be applied back to your university email

 

User login