Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
Loading...
Loading...

HOWTO: Setting Up DMARC with MailMarshal (SEG)

Expand / Collapse


This article applies to:

  • Trustwave MailMarshal (SEG) 8.0 and above
  • DMARC

Question:

  • How do I set up SEG to participate in DMARC?
  • How do I generate a DMARC record for a domain? 

Reply:

Trustwave MailMarshal (SEG) 8.0 and above provides the ability to participate in DMARC (Domain Message Authentication Reporting and Conformance) for email authentication.

When DMARC is configured:

  • MailMarshal will send aggregate reports to the RUA address specified by each sending domain that uses DMARC.
  • MailMarshal can apply the DMARC policy specified by the sending domains (depending on the rules you enable).

This article provides a simple overview of the requirements and procedures to enable DMARC. For more information see the product Help and the related articles listed below.

To set up DMARC:

DMARC requires that you configure SPF and DKIM for message validation. You must also configure at least one of these protocols for outbound messages, so that other servers can validate messages from your domain.

  1. Enable DKIM for each domain.
  2. Enable SPF for each domain.  
  3. Generate and publish a DMARC DNS record for each domain (see below). Ensure that the record is published. The DMARC setup window in the SEG Configurator checks for a valid record.
    • Important: To ensure validation of the record succeeds, this record must exist on the DNS server configured in MailMarshal. If MailMarshal uses an internal DNS server and the public DNS records are not replicated to that server, you must also create the record on the internal server.
  4. Enable DMARC for each domain.
  5. Configure and enable DMARC rules. Three DMARC related rules are included in the default rules for SEG 8.0 and above. The DMARC rules are also added to an upgrade policy set when SEG is upgraded to 8.0 or above.
    • Note that the DMARC policy group is disabled by default, because you must ensure that other configuration is complete before using DMARC.
    • The rule to detect incoming DMARC report email (and move it to a folder for later automatic processing) is evaluated after the rules that apply DMARC policy, because the DMARC RFC states that you should only accept incoming DMARC reports from senders that have correctly configured DMARC. (In SEG 8.2 and above, the default rule explicitly enforces DMARC conformance for reports.)
    • SEG 8.2 and above honors the optional PCT keyword for incoming messages, which specifies that only a certain percentage of mail from a domain should be checked.

DMARC DNS Record basics

The DMARC DNS record specifies how you want other servers to validate messages from your domains, and where they should send reports.

For details of the available options a good starting place is the dmarc.org Overview. See also the specification in RFC 7489.

  • Create a DNS Resource Record of type TEXT with a record name like _dmarc.domain.TLD
    • Note the record name MUST start with _dmarc (including the underscore)
    • For example, the Resource Record name for domain example.com is _dmarc.example.com 
  • The text content of a simple starter record is like the following:

    v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; aspf=s


  • Looking up the record with NSLookup returns a result as shown below:

  • The above record
    • specifies "strict" checking of SPF (the default is "relaxed")
    • Requests reports to the email address shown
    • Specifies a policy of "none" - the recipient should not reject or quarantine any messages simply because they do not align with this DMARC policy (note that the recipient could reject or quarantine the messages for other reasons)
  • After reviewing the reports and confirming that valid messages from your domains do pass evaluation, you can request that recipients take action on messages that do not align with the policy, by changing the policy to "quarantine" or "reject".

Changing the DNS server setting

MailMarshal (supported versions) validates the public availability of DKIM keys using a DNS query from the Array Manager to the DNS servers configured in MailMarshal, and also to a public DNS server (by default using Google public DNS: 8.8.8.8). Using a public DNS server helps to test that the key has replicated widely. This setting is also used for DKIM validation.

For validation checks to work properly, you must ensure that both the local and public DNS environments hold this information. 

You can change the public DNS server used, by making an entry in Management Console Advanced Settings (8.2 and below: editing the Registry).

10.0 and above: 

  1. In the Management Console, add an Advanced Setting as follows:
    • DNS.ThirdPartyServer
    • Type: String
    • Value: the IP address of the DNS server you want to use.
  2. Commit Configuration Changes.
  3. Restart MailMarshal services on the processing servers.

8.2:

  1. On the Array Manager, edit the Registry.
  2. Navigate to the SEG DNS key:
    • In version 8.X: HKEY_LOCAL_MACHINE\SOFTWARE\Trustwave\Secure Email Gateway\Default\DNS
    • For full details of the location for each product version, see article Q10832.
  3. Add a String (REG_SZ) value ThirdPartyServer and set the value to the IP address of the DNS server you want to use.
  4. Commit configuration changes.
  5. Restart the Array Manager service.

For details of the registry locations for each SEG version, see article Q10832.


To contact Trustwave about this article or to request support:


Rate this Article:
     

Related Articles



Add Your Comments


Comment submission is disabled for anonymous users.
Please send feedback to Trustwave Technical Support or the Webmaster
.