Category Archives: IT

DMARC compliance for Office 365 Mail and SiteGround-hosted WordPress

Anticipating Gmail’s new requirements for email senders that are rolling out in February 2024, I started working on getting my 11 email-sending domains in compliance.  I quickly realized that most DMARC compliance guides are written for IT pros, which I am not.  After a few months of working on this project, I finally am happy with the state of my domains and I’d like to share what I’ve learned with those of you who are similarly pretending to be an IT professional.

This guide is most useful if you use…

  • Office365 for your email – I’m a big fan of Office 365 for email…great support, intuitive to use, and keeps you out of the Google ecosystem (but iOS doesn’t always play nicely with it).
  • SiteGround to host your WordPress websites – I’m a HUGE fan of SiteGround.  Once you get out of their intro period, they are pretty dang expensive, but worth every penny if you don’t have the time to deal with bullshit.  I’ve used at least a dozen hosts over the last 20 years, and SiteGround has not disappointed me once since I started with them in 2016.  Uptime is fantastic, their console is easy to use, and their support is absolutely top-notch.

But first, some basics (from a layperson’s perspective).  Basic authentication determines whether emails from your domain are from legitimate senders.  Otherwise, anyone is able to send fake emails from your domain.  The scheme relies on 3 different mechanisms:

  • SPF (Sender Policy Framework) – on a high level, this mechanism tells the world which email servers are permitted to send emails on behalf of your domain.  This information is conveyed to recipient email servers via your SPF record, which is saved as a TXT entry in your DNS records.  This is great, but unfortunately, because the way emails are encoded, if you forward an email from someone else of a different domain (or vice versa), the forwarded email will show up as non-compliant with SPF.
  • DKIM (DomainKeys Identified Mail) – this mechanism includes a digital signature with every email you send, and recipient email servers use a public key to confirm the digital signature is correct.  The public key is stored as either a CNAME or TXT DNS record.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) – this mechanism relies on the recipient email server to check if either SPF or DKIM passes.  If both fail, then your DMARC record will advise on what to do–either reject, quarantine (i.e. put it in someone’s spam box), or nothing (let the email through).  The DMARC record also tells recipient email servers whether or not, as well as where, to send reports about how they’ve handled email from your domain.  There are two types of reports:
    • RUA (aggregate reports) – these are summaries sent at some interval (several hours to days?) about emails received
    • RUF (forensic reports) – these are details sent for each email received.  Apparently, most email servers will not send RUF even if you request them.

Configuring your IT infrastructure so that your emails are in compliance will help to ensure that your domain’s “reputation” will be high, saving your emails from ending up in your recipients’ junk mailboxes.

So…let’s get started on getting you in compliance.  First you’ll need the following:

  1. Access to your Office 365 portal (https://admin.microsoft.com)
  2. Access to your DNS provider (for many of you, this will be your domain registrar, e.g. NameSilo, GoDaddy, etc).  I use DNSMadeEasy.  They are easy enough to use.
  3. Access to the user area in the SiteGround portal (https://tools.siteground.com)
  4. Access to the admin area in your WordPress installation (https://yourdomain.com/WhatEverYouNamedYourWordpressInstallationFolder/wp-admin)

Here’s what you need to do:

Setup SMTP Mail on your WordPress site

Your WordPress site sends emails for various reasons–to indicate plugins have been updated, to send you emails when users submit a contact form, etc.  Because a standard WordPress installation uses the PHP mail() function, the emails that your site sends will most likely fail SPF, DKIM, and DMARC.  Let’s setup SMTP mail to fix that.  Here’s how to do that:

  1. In the SiteGround user portal (https://tools.siteground.com), select the domain that you want to configure.  Navigate to Email | Accounts.
  2. Create a new email account and record the account name and password (might I suggest 1Password as your password manager?).  I recommend something like notifications@yourdomain.com.
  3. Click the 3 vertical dots and then click Mail Configuration.  Navigate to the Manual Settings tab of the popup.
  4. Record the information in the popup (incoming/outgoing server, SMTP port).
  5. Now open your WP console and navigate to the Plugins section.
  6. Click on Add New Plugin, and then search for “fluentsmtp”.  Install the plugin from the results titled “FluentSMTP – WP Mail SMTP, Amazon SES, SendGrid, MailGun and Any SMTP Connector Plugin”.  I chose FluentSMTP because it’s free and the support is pretty good for a free product.  Activate the plugin after installation.
  7. Now go to Settings | FluentSMTP in the WP Console, and navigate to the Settings tab.
  8. Click [something like] “Add Another Connection”.  Select “Other SMTP”.
  9. Enter the following details:
    1. From email: whatever you setup in SiteGround (e.g. notifcations@yourdomain.com)
    2. From name: I recommend “Notifcation: yourdomain.com”
    3. Click Force From Email, Set the return-path to match the From Email, and Force Sender Name
    4. SMTP Host: get from the SiteGround mail configuration
    5. SMTP Port: 587 (same as from the SiteGround mail configuration)
    6. Encryption: TLS
    7. Use Auto TLS: on
    8. Authentication: on
    9. SMTP username: whatever you setup in SiteGround
    10. SMTP password: whatever you setup in SiteGround
  10. Click “Save Connection Settings”
  11. Now navigate to the Email Test tab and do an email test (from the address you configured at SiteGround, to any email account that you have access to).  Note that the test email might fall into your spam box.
  12. Go back to the Settings tab and set these as you wish, but my preferences are as follows:
    1. Log all emails for Reporting: checked
    2. Delete logs: after 2 years
    3. Default connection: whatever is default
    4. Disable sending all emails: unchecked

Configuring your SPF record

  1. Go to your DNS provider.  In the TXT records section, there should already be an SPF record which you specified when you setup your Office 365 email.  It should look something like this v=spf1 include:spf.example.outlook.com -all which covers emails sent from Office 365.  But since we are now also sending emails from your SiteGround SMTP server, we need to combine the SiteGround SPF record (v=spf1 include:_spf.mailspamprotection.com -all) to make this final record for your domain: v=spf1 include:spf.protection.outlook.com include:_spf.mailspamprotection.com -all
  2. Save the updated SPF record.

Configuring your Office 365 DKIM record

  1. Goto https://security.microsoft.com/dkimv2
  2. Click on the domain you want to configure
  3. Record the information in the Publish CNAMEs section in the right flyout window.  This is the Office 365 DKIM info.
  4. Now go to your DNS provider.  In the CNAME records, add the records per the step above (these are examples–be sure to enter the information specific to your domain):

Host Name : selector1._domainkey
Points to address or value: selector1-yourdomain-com._domainkey.yourmaindomain.onmicrosoft.com

Host Name : selector2._domainkey
Points to address or value: selector2-yourdomain-com._domainkey.yourmaindomain.onmicrosoft.com

Now save the record, then go back to https://security.microsoft.com/dkimv2 and in the right flyout window, enable the Sign messages for this domain with DKIM signatures toggle switch.

Configuring your SiteGround DKIM record

Whereas the Office 365 DKIM records are in the CNAME record of your DNS, SiteGround stores it in your TXT DNS record.

  1. Go back to the SiteGround console and navigate to Email | Authentication.  Navigate to the DKIM tab.
  2. Click “copy to clipboard”
  3. If your DNS provider allows you to paste in a zone record, then you can paste your clipboard there (be sure not to append, not overwrite, your existing records!).  If not, add a TXT record named default._domainkey with a TTL of 14400 and a value containing all the text in your clipboard between and including the quotation marks, e.g. "v=DKIM1;k=rsa;p=AVeryLongStringOfRandomCharacters".

Configuring DMARC

Before we implement a DMARC policy (e.g. enforcing either reject or quarantine), you should monitor your RUF/RUA reports for a few weeks/months to see how recipient servers are liking your emails.

Microsoft has partnered with Valimail to offer free DMARC monitoring, but I’ve found their service to be garbage–they give you no specific data–only numbers indicating the percentage of emails that passed/failed SPF, DKIM, and DMARC.  Without knowing the data behind the numbers, all you can do is make changes, see if they result in any improvement in the percentages after you wait for weeks of reports to come in, and continue the “feedback loop”.  It’s like flying an airplane without knowing what the controls do and only getting reports of your altitude every 5 minutes.

So…I’ve been using GlockApps.  Their free tier has unlimited domains and handles up to 10k DMARC messages/month.  There are other free DMARC providers, but none with unlimited domains.  Here’s how to configure their service:

  1. Setup an account at https://app.glockapps.com/signup
  2. Go to the console and navigate to DMARC Analytics | Add Domain.
  3. Enter the domain you want to monitor.
  4. Set your DMARC policy to none
  5. Do not enable “Set a different policy for subdomains” (unless you have subdomains, in which case this guide does not exactly pertain to your situation)
  6. Do not mess with the advanced options.
  7. Click Next
  8. Click the copy to clipboard icon.
  9. Go to your DNS provider’s TXT record editor and add a TXT record with hostname _dmarc and value set to whatever is in your clipboard.

Depending on how much email you and your domain send, it may take a few days for your domain to show up in the GlockApps Domains Overview.  At this point, you’ll want to send several emails from your WordPress site (e.g. send test messages from FluentSMTP as we did above, submit contact forms on your site, etc).  Put on your patience pants.

Check to make sure all is correct

There are a few things you can do to ensure that you’ve configured your email authentication correctly–I recommend doing them all:

  1. Use https://mxtoolbox.com/dmarc.aspx, enter your domain, and click “DMARC Lookup”.  Aside from having a DMARC policy not enabled, you should have all green check marks.
  2. Send emails from Office 365 as well as from the FluentSMTP test email to ping@tools.mxtoolbox.com.  You’ll receive an email response with a detailed deliverability report.
  3. Within GlockApps, there are options for additional tests, but you only get 2 per month, so wait until the previous 2 tools give good results before you use these.

Monitor and adjust

Once all is configured as shown above, you’ll need to monitor the DMARC results in GlockApps.  With any luck, your compliance rate will be 100% and you’ll be ready to implement an actual DMARC policy (reject or quarantine).  You may see some emails failing SPF, which should (I think) correspond to the number of emails in the “Forward” column.  You may be surprised to see some emails in the “Unknown” column–and when you click on those, you may see that spammers all over the world are sending emails on behalf of your domain.  This whole effort that you’ve gone through will ensure that those spammers’ emails never make it to anyone’s inbox–and that your legitimate emails will always get to their intended recipients.

If you see other unknowns, then perhaps you are using another 3rd party email provider (e.g. MailChimp) for mass emails–in which case this guide will need some adjustment.

If you are able to maintain a compliance rate of 100% and/or the only DMARC failures are the spammers for several weeks, then you can modify the p=none part of your DMARC record to p=quarantine (spammers go to junk mail) or p=reject (spammers get rejected).  You can also gradually increase the percentage of emails that will get quarantined or rejected–but if you are hitting 100% compliance, then there’s no need to ease into this (I think).  As of time of publication, there are a few weeks until Google’s deadline, so I’m going to monitor for a bit longer before implementing the policy.

Well, shit, this turned out way longer and more complicated than I had hoped–but I still hope it helps anyone who’s in the same IT infrastructure boat as me.

Xfinity/Citrix Data Breach

I guess the new standard for companies handling their data breaches is to tell you it happened, telling you what bullshit measures they are doing to not-really rectify the situation, pushing the burden onto you to mitigate the damage of their fuckup, and not apologizing for the fuckup at all.

I’m no data security expert, but it seems to me that the birthdays, SSN digits, and secret questions/answers could have been hashed, and that would have significantly mitigated the potential impact of the breach.

Fixing recurring Windows Installer whenever Explorer is run

Event viewer

My PC (Win 10 x64) was having an issue where Windows Installer would run every time Windows Explorer was run (including showing the desktop on startup).  This somehow locked up the PC almost completely, except running task manager so that I could kill Explorer.  None of the suggested fixes (msiexec /Unregister, msiexec/regserver; DISM.exe /Online /Cleanup-image /Restorehealth; sfc /scannow) seemed to help.  So…I checked out the Event Viewer and saw the warning shown above, Googled “msvcr110.dll does not exist” and saw that I needed to repair the Visual C++ Redistributable for Visual Studio 2012 Update 4. And that took care of it–right before I was about to wipe the drive and reinstall clean.  I hadn’t seen this fix anywhere else, so I thought I’d post it for some other poor soul who manages to make their way here.