HashGate: An intrusion detection tool

HashGate is a simple intrusion detection tool we wrote for use internally and in customer environments to monitor files and alert us on any unauthorised changes to them.

We try very hard not to re-invent the wheel and are already big users of tools such as Tripwire and Rookit Hunter but we wanted something lightweight for monitoring site files, not system files.

HashGate is written in Python using only core modules and aims to work on all platforms that can run Python 2.7, not just Linux!

Our main use for HashGate is for monitoring files on WordPress & Magento installations which more commonly are exposed to vulnerabilities allowing hackers to modify files. HashGate records the hashsum of all files in the specified directory and stores them for checking periodically, we run our checks hourly via cron.

Below is an basic example output where a file has been modified:

alex@dogsbody-alex:~$ ./hashgate.py -ca /tmp/files.cache -f /home/alex/Documents/Junk/ -t check
The following files were modified:

Other features of HashGate include whitelisting, which allows us to ignore files that frequently change and don’t need to be monitored such as WordPress’ cache files or Magento’s sessions directory.

There is also VirusTotal checking, this is where HashGate will check flagged files hashes against VirusTotal’s database of malicious files to determine if the change was malicious or not. Due to the nature of VirusTotal’s API we’re only able to do 4 requests per minute so if lot’s of files are flagged it will add some extra time to hash checks.

We have recently open sourced this tool and you can find some more information and a list of the full features and usage in the Github repo, if you feel something can be written better or there’s a feature you’d like to add we invite you to contribute and help us build a better tool. We make use of tools like HashGate in some of our server monitoring packages so be sure to check them out and get in contact if they could be of use.

PHP 5.5 support will stop on the 10 July 2016

Quick Public Safety Announcement, PHP 5.5 is end of life (EOL) on the 10 July 2016.

Anything not running PHP version 5.6 or newer exposes your site to significant security vulnerabilities.

We have ensured that all our customers are safe and ready. Unsure if you are affected? Want a hand upgrading? Get in touch!



I am a big fan of graphs, Jordi Boggiano has provided this is a great overview of the PHP versions out there in the wild!

We are very happy to see a big drop in PHP 5.3 and 5.4 since they have long passed end of life and a surprisingly quick rise in the brand new PHP 7.0. 🙂


Feature image by See1,Do1,Teach1 licensed CC BY 2.0.

Pushover Alerts

Alerts & Webhooks with AWS Lambda

Here at Dogsbody Technology we monitor servers and services for hundreds of clients, you may have read our previous blog post talking about our Warboard and how we make use of it. This blog post covers the other tools we use for responding to incidents and issues real time, our Dogsbody Technology Webhooks.

The main thing we use the webhooks for are Pingdom, Newrelic & Sirportly alerts. When an incident is triggered in Pingdom or Newrelic they will make an API call to our webhook with the relevant information we require to investigate an incident, the webhook will then determine the priority of the incident and send an alert to our Pushover user accounts so we are alerted and can respond to the incident.

High priority alerts, such as site outages also trigger a rotating blue police style light which is accompanied by a siren sound from the office speaker.


Office Siren

The Dogsbody Technology office siren


We also use the webhooks to notify a user when certain interactions happen in our ticketing system Sirportly, such as being assigned a new ticket or when one of their existing tickets is replied to.

To ensure our webhooks would have near to 100% uptime and we wouldn’t miss an alert, we decided the best place to host them would be using AWS Lambda & AWS API Gateway. These two services combined allow us to run the webhooks with Amazon’s high availability infrastructure while only paying small amounts on a per request/alert basis, which is the perfect type of model for this service.

To put into perspective how cost effective AWS’ pricing model for our alerts is, last month (June 2016) we received 25,282 alerts for all of our endpoints combined. This worked out at a total monthly cost of … $0.10! AWS actually provide you with a free amount of lambda execution time per month which we haven’t even reached yet, we’re only getting charged that 10 cents for the API Gateway.

Let us know if you find any of the services and technologies mentioned above interesting and we can write some more in-depth blog posts on those subjects, and even some guides on using them. The alerts talked about in this blog post come with the majority of our server monitoring packages, so be sure to get in contact if you need any of our services.

Let’s Encrypt: Security Everywhere

Let’s Encrypt is a new Certificate Authority (CA) who are making waves in the web community. They have lowered the access barrier for SSL certificates significantly and are pushing their competition to improve; fast.

“A Certificate Authority is an entity that validates other digital certificates… …Creating a Chain of Trust between a website and the browser.”

Read more about Certificate Authorities or how to trust over the Internet.

Why Lets Encrypt is revolutionary:

  • Let’s Encrypt removes the pay wall for SSL certificate’s making them free for everyone.
  • Its quick. Seemingly instant certificate authentication and provisioning.
  • Open client options for many different programming languages and environments.
  • Certbot (the official client, developed by the Electronic Frontier Foundation (EFF)) is incredibly simple to set up and run HTTPS in seconds. See for yourself.
  • Automated SSL regeneration. A new certificate just when the old one expires.
  • Raising the standards for CA security checks. Let’s Encrypt have implemented new security checks which ensure that you are the domains owner and that it’s secure to issue you the certificate. Read more.
  • Short validation periods. Let’s Encrypt certificates are only valid for three months which in comparison to other CA signed certificates is shorter. You may be thinking this is bad, long validation periods means less work to maintain. But should the next Heartbleed vulnerability come along and your certificate is leaked to the public, the perpetrator only has less than three months to use it then it will no longer be valid.
  • Supported, as of last year Let’s Encrypt are trusted in most browsers. Test it for yourself. Read more.

It’s free, easy and simple to do so there is no reason not to get started straight away.

Quick (nearly instant) certificate provisioning is our favourite benefit. We often have new customers come to us that have been caught out by expiring SSL certificates not leaving enough time for the renewal to take place, which with Extended Validation certificates can be weeks! Let’s Encrypt is our first port of call to mitigate the missing certificate. Giving us a temporary solution while their other certificate is renewed.

At Dogsbody Technology we love SSL and have already started implementing Let’s Encrypt when we can. If you want to see the benefit of SSL drop us a line.

Feature image made by Got Credit licensed CC BY 2.0.

IPv6 Day 2016

Today is IPv6 day. IPv6 day aims to evaluate and promote public IPv6 deployment as it was designed to eventually completely replace IPv4.

We embrace IPv6 technology at Dogsbody Technology and want to help promote it, so we thought we’d write a blog post telling you why we think it’s great.

But first, what is IPv6?

IPv6 was invented to address the issue of IPv4 exhaustion. It allows for a much larger number of IP (Internet Protocol) addresses, which is what computers use to identify and communicate with one another over the internet. Once all of these addresses are taken, no one new would be able to connect to the internet. There are around 3.7 billion public IPv4 addresses, which are now virtually exhausted due to the ever growing number of computers and people who are connected to the web. Compare this with roughly 340 undecillion, or 340 trillion, trillion, trillion that you get with IPv6.

With IPv6 every human on the planet could use billions of addresses a second and we’d still not run out.

An IPv6 address is written differently and so needs different DNS records.  If you do a DNS query on www.dogsbodytechnology.com you will see two responses. A traditional A record that includes the IPv4 address and a new AAAA record that shows the IPv6 address:

www.dogsbodytechnology.com. 900 IN A
www.dogsbodytechnology.com. 900 IN AAAA 2a01:7e00::31:9003

IPv4 Addresses are in the format “ddd.ddd.ddd.ddd” where each “ddd” ranges from 0-255.

IPv6 addresses are in the format “hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh” where each “h” is the value 0-15 written in hexadecimal.

IPv6 addresses can also be shortened so that leading zeroes can be removed (like IPv4) and consecutive blocks of 0000 can be replaced by a double colon (::) e.g.


There are lots of fantastic guides explaining how computers understand and use these addresses that will do a much better job of explaining than we could hope for in a small blog post.


  • Won’t run out.
  • Routing is more efficient.
  • Makes address allocation and network management simpler.
  • Improved end-to-end connection, helping things such as file sharing and online gaming.


  • Makes addresses harder to remember for humans.
  • Can make it easier to track an individual’s use of the internet.
  • New hardware may need to be purchased.
  • It’s going to take a long time to transition fully.

Some of the above disadvantages are lessened and/or avoided with the use of a dual stack (running IPv4 and IPv6 side-by-side)

Regardless of the down sides, we’re big fans of IPv6, and all of our servers use it where possible.

There is even a chance that you’re using it right now to view this website.  Contact Us if you want to make sure future visitors can access your site over IPv6.

Certificate Authorities or how to trust over the internet

A common misconception we see all the time is that HTTPS is only useful for scrambling (encrypting) connections between you and a website, but this is only half of its potential.

So how do we know we are connected to Facebook’s servers when we access www.facebook.com?

HTTPS ensures this, by making two important aspects of security possible: encryption and authentication. It does this by sending additional data (SSL certificates) before each connection. This certificate tells the client how to encrypt their connection and which Certificate Authority will authenticate who they are.

A Certificate Authority is an entity that validates other digital certificates.  They do this by “signing” certificates (with each others keys) and creating a Chain of Trust between a website and the browser.

This is the chain of trust for https://www.dogsbody.com (feel free to check this yourself in your browser now)


  1. *.dogsbodytechnology.com
    The first certificate your browser receives is the site certificate. This certificate details all of the domains that it is applicable for, in this case any domain ending dogsbodytechnology.com. As well as an “Issued By” field which details the certificate that signed it, giving your browser the information to verify it.
    When setting up a secure website (HTTPS) one of the first steps is to get a certificate authority to sign your certificate. Their signature connects you to a root certificate which browsers and software knows it can trust.
    Comodo signed our certificate so our “Issued By” field points to them.
  2. COMODO RSA Domain Validation Secure Server CA
    This is one of Comodo’s many intermediate certificates. There can be multiple intermediate certificates in the certificate hierarchy however each extra hop reduces trust.
    This certificate is not known by the browser so the webserver should send this certificate (and all intermediate certs) with the site certificate. This is sometimes known as the certificate bundle.
    This certificate’s “Issued By” field links to the root certificate giving us the next link in the chain to verify this certificate.
  3. COMODO RSA Certification Authority
    This is a root certificate, it is stored locally on your operating system (OS) with other root certificates your OS trusts. These are the master certificates of certificate authorities who have been thoroughly authenticated so your browser can trust them definitively.
    Some products such as FireFox for example, provide their own selection of root certificates which is used over the operating systems.
    While each certificate stores the field “Issued By” to verify it, root certificates are Issued By themselves, so no further checking is possible or necessary, they are trusted absolutely. This is a Trust Anchor, the end of the verification process.

Now that the browser can link your certificate with a root certificate it knows it is talking to authorized servers for the site and the rest of the connection can continue.

We secure websites every week contact us today and see how we can help you.

The Warboard

The Dogsbody Technology Warboard sits on the wall in our office and allows us to see a detailed overview of the infrastructure we monitor real time, this has proved it’s self to be invaluable for spotting potential issues and remedying them before they ever become an issue.

We’re responsible for monitoring and maintaining hundreds of servers on a daily basis.  Checking the status of this infrastructure manually would be virtually impossible. To make this job easier we use tools such as Pingdom and NewRelic however we still felt the need for a high level overview of all servers.

When there is an issue with either a service failing on a server, or the health of a server deteriorates Pingdom and NewRelic will alert us real time via custom webhooks we have written. These are great for reacting to an issue when it happens, however it doesn’t give us a clear overview of the infrastructure we monitor before an issue occurs, this is why we created the Warboard.

The Warboard is displayed in such as way that we only see the metrics we need to. Services at the top of the Pingdom column are ordered by highest response rate, servers in NewRelic are ordered by the highest metric for each server (if CPU utilisation was a higher percentage than memory, disk usage and disk IO it would be used). We display the Warboard on a wall mounted TV for the whole team to see.


Example screenshot of the warboard

In the Pingdom column red checks are checks that are currently down, blue checks are paused and green checks are up. In the NewRelic column red checks are servers that have hit their high threshold on their policy, amber checks have hit their warning threshold, blue checks are servers that are no longer reporting and green checks are servers that have not reached a threshold.

We also have a column for Sirportly, our ticketing system. This shows how many tickets each team member has. Below this is an overview of events in our Google Calendar where we can see upcoming events and scheduled maintenance.

The Warboard backend is all written in Python and the frontend is Python (Flask) using the Jinja2 templating engine. We’ve made the Warboard public on Github, so feel free to contribute, modify it and use it in your own environment if you please.

If you’d like us to monitor your infrastructure be sure to take a look at our maintenance packages and get in contact.

What time is it? – About NTP

In this blog post we’ll talk about time, how it works, why it’s important to computers, and how NTP can be used to manage the time on computer systems.

“You may delay, but time will not.”
― Benjamin Franklin

Intro to NTP

NTP (Network Time Protocol) allows computers on a network to synchronise their system clocks, with accuracy of as little as a few milliseconds. It does this by exchanging packets over the network and performing calculations based on the contents of these packets. Here is a simplified breakdown of this process, where two systems A (client) and B (server), synchronise their time:

  1. System A inserts it’s current time into a packet, and sends this to system B
  2. Upon receiving the packet from system A, system B then inserts it’s current time into the packet and sends it back to system A
  3. When system system A receives this packet, it will use the contents of the packet to estimate the time difference between the systems
  4. System A will use this time difference to adjust the system time, so that it is in sync with system B

This is often repeated multiple times, with every iteration resulting in the times of the systems getting closer and closer together. The above steps assume that system B’s time is correct.

Why is NTP needed?

You may be wondering why computers go through so much “trouble” to synchronise their clocks, or why there is an entire protocol dedicated to it; people’s watches are often out by a couple of minutes, and they manage just fine, why are computers any different? Well that’s just it, computers are very different. The smallest unit of time most people use every day is seconds. They microwave their lunch for 45 seconds, they wait 40 seconds for their tea to brew, they call someone back in 30 seconds. That’s fine, and it doesn’t really matter if you cook your lunch for a few seconds longer, as not much happens in a second.

However, a second for a computer is a huge amount of time. A moderately powerful modern computer can perform 14,000,000,000 (that’s 14 billion) operations every second. So a one second disparity between the times on systems could result in an extra 14 billion operations taking place. To be completely fair, each of these many operations represents very little in the grand scheme of things, but the example still holds: computers are extremely time-sensitive.

What happens when system times are out of sync?

When the times on systems are out of sync, some really odd and horrible things can happen:

  • Logs on different systems won’t correspond to each other. Lets say your application breaks, and you want to look through the logs and see what the problem was. You know the issue happened at, for example, 03:17:54. When you check the logs, you look for the entries at 3AM and try to figure out what went wrong. What if one of the systems’ time is wrong? Even though a log entry says something happened at 3AM, you could actually be looking at what happened at 4AM. This can me manageable if you’re only comparing logs between 2 systems, but when you start dealing with more and more systems, this becomes impossible pretty quickly.
  • Tracing emails can become very difficult. When you send an email, chances are it passes through multiple servers before reaching its destination. If you want to debug an email issue, you’re probably going to be checking headers (additional bits of data transmitted with the message), which contain timestamps added by each server the email passes through. If the times are out of sync on the systems, it can make it really difficult to trace the path of a message.
  • CRON jobs could run at the wrong time. Let’s say you have a CRON job that runs at 9PM. Its purpose is to, for example, kick all users off of the system and backup their files from that day. But, what if the system time is wrong, and this CRON ends up running at 2PM instead? People would be kicked off of the system in the middle of the working day, potentially resulting in a big loss of data and/or productivity.
  • Authentication services can be affected. Lots of two-factor authentication systems work on the idea of a one-time password. This is usually calculated based on a shared secret key, and the current time stamp. In order to authenticate successfully, a user needs to input the one-time password that the server is expecting. What happens if the client and server’s system times are different? Authentication fails, because the server is expecting a different key than the one provided by the user.

How to set up NTP on a Linux system & why servers should use UTC regardless of time zone

Setting up a Linux system to synchronise its system clock is really easy, and we’d always recommend doing this, especially on servers.

First, make sure you have an NTP client installed on your system. Most systems will come with one installed by default. A lot of the servers we manage run Ubuntu, so I’ll show you how to check an NTP client is installed on an Ubuntu system. Run this command in a terminal:

dpkg --list | grep ntp

You should see the package ntp listed. If nothing is returned, then you don’t have an NTP client installed. You can install it by running the following command with root privileges

sudo apt-get install ntp

The most important thing to configure with NTP is which servers to synchronise time with. These are defined in the /etc/ntp.conf file. If you check this file, you’ll find lines looking like the following:

server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org

These lines specify which NTP servers should be used. We typically change these to use the “standard” UK time-servers, like so:

server 0.uk.pool.ntp.org
server 1.uk.pool.ntp.org
server 2.uk.pool.ntp.org
server 3.uk.pool.ntp.org

These servers are all members of the NTP pool project. The NTP pool is a collection of publicly accessible NTP servers, which anyone can join (though there are a few requirements). We at Dogsbody Technology Ltd actually have a number of our own servers in the pool, providing time synchronisation capabilities for everybody to use. This helps to keep everybody’s system times in sync.

If you’ve having issues with NTP, or anything else for that matter, on your servers, then please get in touch and we’ll be happy to help.

Feature image made by Sean MacEntee licensed CC BY 2.0

HSTS Header

HTTPS Everywhere

“HTTPS Everywhere” is an increasingly popular trend among websites which gives added security, speed and SEO benefits. In August 2014, Google announced that it would be adjusting it’s search engine ranking algorithm to benefit HTTPS only sites, this was one of the key announcements that started the trend of sites going HTTPS everywhere. There’s also been numerous leaks and blog posts talking about the NSA & GCHQ intercepting communications to and from insecure HTTP sites.

In the past, one of reasons websites weren’t HTTPS everywhere was due to the added latency from the overhead of the HTTPS connection. With a slow internet connection and slower servers by todays standard this caused the sites to become sluggish which obviously isn’t great from a user experience point of view. Now that bandwidth and server performance has improved, the overhead is negligible, there have also been improvements such as SPDY and HTTP/2 which can drastically improve a websites performance over HTTPS, we will be covering how these work in future blog posts.

There are a few steps you can do to get your website running HTTPS everywhere:

  • Redirecting all HTTP requests to HTTPS; this can be done in your apache or nginx configuration and will tell web browsers that any request they make for content over HTTP should be redirected to the HTTPS equivalent URL. Ideally you would use a 301 (permanent) redirect for this, redirecting HTTP requests to HTTPS is something we do for the Dogsbody Technology site.
  • Add the HSTS (HTTP Strict Transport Security) header to your website; again this is done in your apache or nginx configuration. This header tells browsers that it should only access the website over HTTPS, the browser will make sure not to request HTTP pages until the “max-age” time is reached (how long the browser should cache the HSTS setting for). There is also an option “includeSubdomains” which tells the browser any subdomain on for the site should also be served over HTTPS, you should be careful when setting this if you have any subdomains that won’t work over HTTPS. We don’t include subdomains in our HSTS settings as we have a few subdomains out of our control that can’t be served over HTTPS.
  • The last thing you should do, only if you have the “includeSubdomains” setting mentioned above is add your website to the HSTS preload list. The HSTS preload list is a list of domains included by browsers that will serve over HTTPS by default without having to perform an initial HTTP request to the website. For this to work you will also need an additional “preload” option specified in your web servers HSTS configuration. You can submit your site to the HSTS preload list here.

Another good option is the HTTPS Everywhere browser plugin from the EFF, it works to achieve the same result as using HSTS preload and act as a list of rules browsers should follow for websites. It allows a finer grain control than HSTS and is perfect for domains like ours where we can’t include every subdomain, you can write your own ruleset for the plugin and do a git pull request to get your website in the next release they do. You can see our pull request where we added the rules for dogsbodytechnology.com & dogsbodyhosting.net and some specific subdomains.

Once you’ve done all of the above steps you can be pretty happy that your site is HTTPS everywhere, and the majority of all traffic to your website will be served over HTTPS (some older browsers don’t support the HSTS header).

If you think going HTTPS everywhere is the next step for you be sure to get in contact with us and we can help you achieve that!

The Dark Art of Email Deliverability

We often get questions over the technologies which help get your legitimate email delivered.  There are three main ones:

  • SPF – Used to lock down email sources to your servers
  • DKIM – To authenticate your sent emails
  • DMARC – For real world email reporting and DKIM enforcement

Email is vital to any organisation. Ensuring your emails are delivered can seem like a dark art. There are many systems at play to cut down on spam and other fraudulent emails. Over 80% of the email we receive at Dogsbody Technology is filtered out as SPAM. It can be hard for a system to recognise your legitimate email.

This makes email one of the more difficult technologies to get right.

“The Dark Arts are many, varied, ever-changing, and eternal”.
– Professor Severus Snape



Our example features three characters: Alice, Bob and Sybil.

  • Alice is sending emails to Bob.
  • Bob receiving emails through Google’s Gmail.
  • Sybil is sending emails to Bob pretending to be Alice.

SPF, DKIM and DMARC is checked by the receiving email system and will affect how it handles the email. Larger email providers: Gmail, Hotmail, Yahoo, etc., are more likely to check the use of these technologies as they suffer from more SPAM than smaller hosts.


Sender Policy Framework; SPF

SPF is a DNS record which identifies all email sources permitted for your domain.

When an email is received the SPF record is looked up by the receiving mail server and the source IP from the email is then cross-referenced to check that it is in the SPF record.

Example SPF record for Alice’s server, example.com:

example.com. IN TXT "v=spf1 ip4: ~all"

e.g. when Alice sends an email from her domain (example.com) to Bob, Gmail receives this email and gets the source IP ( Gmail then looks up the SPF record for ‘example.com’ which lists ‘’ as an authorised server. Gmail knows Alice has allowed this and passes the email onto Bob.

When Sybil emails Bob as ‘example.com’ (Alice’s domain), Gmail receives the SPAM email and gets the emails source IP ( When Gmail looks up the SPF record for ‘example.com’ it doesn’t list ‘’ so Gmail will flag the email as SPAM.

This means that all sources sending email for your domain needs to be listed. This may include Mandrill, Google Apps for business, Socket labs, AWS SES, FreeAgent, etc.

DomainKey Identified Mail; DKIM

DKIM is a signature added to the header of an email before it is sent into the public internet. This signature shows that you are taking ownership of your email and allows any recipients to prove that.

The DKIM signature is generated with a private key and is based on the email’s contents, this make it unique to you and your email. For the receiving server to authenticate the signature a public key related to the private key is published in a DNS record. With the public key the receiving server can confirm that the DKIM signature was generated by your key. If the public key doesn’t match the signature the email will be considered as SPAM.

Example DKIM record for Alice’s server, example.com:

selector._domainkey.example.com IN TXT "v=DKIM1; p=MIGfMA0GCSq..."

For example when Alice sends an email to Bob, her server will generate and add a DKIM header to it. When Gmail receives this email it sees the DKIM header and looks up the DKIM public key record. It will check the DKIM signature against the public key. Since the email was sent through Alice’s servers the signature matches and gmail will pass the email onto Bob.

When Sybil emails Bob as Alice, Sybil’s server can generate a DKIM header, but when Gmail receives it and looks up the Signature against example.com (Alice’s) DKIM public key it will not match and Gmail will flag the email as spam. This also means that if Sybil intercepts a signed email before it reaches Gmail and changes its contents, the signature will no longer match which will flag Gmail that it had been changed.

Note that DKIM is only checked reactively, when the header is seen in an email. This is unlike SPF records which Gmail will check pro-actively.


Domain-based Message Authentication, Reporting & Conformance; DMARC

DMARC is a DNS record containing information regarding which anti-spam technologies the sending domain is using, and telling receivers to report back what they see.

When an email is received the receiving server looks up the DMARC record for the sender. This record includes flags detailing if SPF and/or DKIM are in use. The receiving server is then able to use this extra information to ensure that the received email is authenticated as the sender intended. If an email comes in which doesn’t meet the SPF and DKIM information provided by the DMARC record, the DMARC record also specifies guidance of how the receiver should act in the case of an authentication failure. e.g. If the message should be let through, put in junk or rejected completely.

Additionally, each ISP that supports DMARC is encouraged to send a report to the contact specified in the DMARC record. The report shows totals of email received and how the ISP dealt with these emails. The ISP can send a report at any time after it starts receiving emails, this is often daily.

Example DMARC record for Alice’s server, example.com:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com;"

e.g. When Alice sends an email to Bob, Gmail will receive her email and look up the example.com DMARC record. Gmail will then check that the email it received uses DKIM and SPF to authenticate as set in the DMARC record. It does and Gmail will pass it onto Bob.

If Sybil sends an email as example.com to Bob, Gmail will receive it and look up the DMARC record for example.com. It then checks that SPF and DKIM were used to authenticate the email and it will fail as neither SPF or DKIM will match the DMARC record. Gmail may then follow the DMARC policy ‘quarantine’ and put Sybil’s email into Bobs Junk mail folder. Gmail can then report to Alice that it received an email from the server ‘’ (example.net) spoofing example.com, and that it failed SPF and DKIM checks.

DMARC reports will come from each receiving server and a spammer can easily send thousands and thousands of emails in an instant. These reports can quickly build up. Dmarcian is a tool which will break down these report into usable graphs and summaries helping you understand them.


These reports show all sources of emails sent from the domain and if DKIM and/or SPF was used to authenticate them, providing real world information on how your domain’s emails are being received out on the internet. It shows if there are any unknown sources impersonating the domain. All of this helps to understand the domain’s email reputation and how deliverable emails are.

DMARC gives you information. Information is power.


Globally SPAM has been going down and it will continue to do so only if more email systems implement these technologies. These have been just one example of how SPF, DKIM and DMARC can protect a domain. There are many more implementations that have their own specific requirements. If you want to improve the deliverability or want more information on how your emails looks to others, these technologies will give you this advantage. Don’t let Sybil spoof you.

Let us build your perfect email infrastructure.


Icons in used in images made by Freepik from www.flaticon.com is licensed by CC BY 3.0.
Feature image made by Christian Barmala licensed CC BY 2.0.