University of Wisconsin–Madison

Email Authenticity

Achieving email authenticity is part of an ongoing effort to protect users from phishing and improve the reputation of email sent from UW–‍Madison.

Campus email administrators are deploying Domain-based Message Authentication, Reporting & Conformance (DMARC) to provide campus units (email-domain owners) stronger control on preventing illegitimate use of UW–‍Madison email addresses.

Messages are DMARC aligned if they pass SPF or DKIM checks, and the domain in the From header matches the results of SPF/DKIM.

DMARC allows email providers to verify that email was sent from a valid UW-Madison address and not from phishers, spammers, or other unverified sources.



Implementing DMARC

Campus email administrators began monitoring spoofed emails in 2017, for the purpose of measuring the extent of phishing and accountability of the UW–‍Madison brand.

After reviewing this data, along with world-wide trends from large email providers (such as Gmail) starting to require all email senders to adopt DMARC, campus email administrators determined the need to begin implementing DMARC for all UW–‍Madison domains.

Emails that are not sent by an approved/verified email service will be affected by these changes.

Approved & Unapproved Email Services


—UW-Madison Office 365 via web browser, desktop app, and mobile app

  • End-users sending outbound email
  • Office 365 Add-ons for mail-merge functionality

—List servers that are configured to work with DMARC

  • UW-Madison email lists : Configure your WiscList with “Header Rewrites” setting “From:” with the following exact text: “‘%%merge inmail_.hdrfrom_%%’ via” <%%email.list%%>
  • Google Groups will use the domain in the From header when DMARC is in effect
  • Departmental and off-campus list servers need to be updated to support DMARC

—Sending email using any other email service requires campus email administrator coordination to work with DMARC

  • We recommend using a subdomain instead of (SPF and DKIM need to be configured based on the From address being used in mailings)
  • The campus SMTP Relay service supports SPF (DKIM support TBD)
  • Third party email service providers (e.g. Mailchimp, Qualtrics, etc)

—Systems that are able to authorize end-users’ use of their own email address within the system


—Third-party email services that are not configured to work with the new DMARC controls

  • Any vendor using off-campus servers

—Non-UW-Madison email accounts that send as a address

  • E.g., a or address set to send as a address

—Third-party email scripts/servers that don’t send email using on-campus mail services

Plan for sending email

Contact the DoIT Help Desk

You will need to provide the following information:

  • Vendor/Service name
  • Email address you would like to send from
  • Recipient Types:
    • 100% UW–‍Madison users
    • 100% non-UW–‍Madison users
    • Both UW–‍Madison and non-UW–‍Madison users

Test for DMARC Effect on Emails

Include in all of your email campaigns. Contact the DoIT Help Desk and ask to verify messages are passing DMARC tests. Please include the Date/Time, Subject, and From address of the messages that you would like examined. Campus email administrators will consult with you to determine if improvements are necessary


Best Practices

Use a vendor’s domain, if provided.

  • If your vendor doesn’t have a domain, use a departmental or project specific domain (
  • If you don’t have a departmental domain or are unsure if you have one, please contact the DoIT Help Desk for help
  • Please note, the domain is only to be used by individuals sending from Office 365 and other systems that are able to authorize end-users’ use of their own email address within the system.

Use your email address in the Reply-to section if you want to receive replies.

  • If you are not sure what email address to use, contact the DoIT Help Desk

To pass DMARC: Use SPF and/or DKIM, with results aligned with the domain in the From header.

Request a Consultation

Need help developing a plan for sending DMARC-protected email? Fill out the form below for a one-on-one consultation.

Email Authenticity Consultation Form

Project Timeline

Applies to the domain. Subdomains may have a different timeline depending on conversations campus email administrators will have with domain owners.

Icon magnifying glass
  • Customer engagement presentation to TAG and governance groups
  • Mailing list providers (e.g. Google Groups and Mailman servers) changed to send DMARC compliant email for senders
  • Providing consultation on the use of sub-domains (e.g.,
  • Unnapproved/unverified email inbound to UW-Madison Office 365 will have the From header rewritten and annotated with a warning (conditionally, based on risk) as a way to raise awareness about email that isn’t verified by DMARC, as well as a way to mitigate some inbound threats
Icon gears
  • Continue backfilling DMARC records for sub-domains. Sub-domains without a record will inherit an implicit DMARC policy in 2019-2020.
  • Drop in sessions and continued consultation efforts
  • Continue to advocate the use of sub-domains and SMTP relay service
  • March: SPF policy published for (SPF record changed ~all)
  • April: 1% of unverified mail affected (DMARC record changed to pct=1)
  • May: 10% of unverified mail affected (DMARC record changed to pct=10)
  • June: 50% of unverified mail affected (DMARC record changed to pct=50)
  • July: 100% of unverified mail affected (DMARC record changed to pct=100)
Line art image of a power button
  • Campus implementation in progress.  Individuals affected by DMARC should consult with the UW-Madison Email team.
  • DMARC consultation still available as a service provided by the UW-Madison Email team