Picking a Good Password is an important aspect of computer security. A poorly chosen password may result in unauthorized access and/or exploitation of systems and resources. All users, including clients, contractors and vendors with access to your systems, are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

Complex passwords which are not easily remembered to typed are no good, as are passwords with difficult to find special characters! When Picking a Good Password, try to create passwords that are both secure and can be easily remembered. One way to do this is to create a password based on a saying, song title, affirmation, or other phrases.

For example: “This May be 1 Way 2 Remember”

This password is long, uses Upper and Lower Case characters, Numbers and punctuation (spaces) and uses these in a non-natural or grammatically incorrect manner. It can be remembered easy and typed quickly and naturally making it harder for people to catch by looking over your shoulder and even if someone guessed it they would still need to know exactly how you have typed or modified it.  You could also use a variant of this such as:

“THIS may be1 way2 REMEBER”

“TmB1w2R3m3mb3r!”

“Tmb1W>r3meber~”

“This£May $e 111 Way 2 R3m3mb3r”

or some other weird and wonderful variation, the weirder the better!

NOTE: Do not use either of these examples as passwords!

However please be mindful that some systems have strange and pointless password restrictions such as no spaces or maximum lengths, so there is no one size fits all approach!


When Picking a Good Password, remember, Length beats complexity every time however the strongest passwords have the following characteristics:

Contain at least three of the five following character classes:
Lower case characters
Upper case characters
Numbers
Punctuation
“Special” characters (e.g. @#$%^&*()_+|~-=\`{}[]:”;'<>/ and space etc)
Contain at least twenty (20) alphanumeric characters.


Weak passwords or Passwords with the following characteristics are normally prohibited and should be avoided:

Short passwords (containing less than twenty characters, yes 20!).
A password which contains a word found in a dictionary (English or foreign) unless it is a combination of at least 4 such words constructed in such a way so as to meet the minimum standards set out above.
The password is a common usage word such as:
Names of family, pets, friends, co-workers, fantasy characters, names of celebrities or other persons of note, sports team names or player’s names, etc.
Computer terms and names, commands, sites, companies, hardware, software.
OR Any derivative of a word from the list above!
Birthdays and other personal information such as addresses and phone numbers.
Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321,123456789 etc.
Any of the above spelt backwards.
Any of the above preceded or followed by a digit (e.g., secret1, 1secret).
Any dictionary word with numbers replacing characters in a predictable or formulaic manner such as “w00d”, “5p0rt” or “313ph4nt” etc.  


Password Protection Standards:

Always use different passwords for each account/website and use different passwords from other non-Company accounts or personal accounts.
Passwords should never be written down or stored in online password managers.
Do not reveal a password in email, chat, or other electronic communication.
Do not speak about a password in front of others.
Do not hint at the format of a password (e.g., “my family name”).
Do not reveal a password on questionnaires or security forms.
Always decline the use of the “Remember Password” feature of applications such as web browsers.


If an account or password is compromised or you have any reason whatsoever to suspect it may have been compromised in any way you must report the incident to the IT / Data Protection lead in your Company and If you’re a Welgo Customer to our IT Team.


Most importantly of all use Two Factor authentication where available and remember When Picking a Good Password, Length beats complexity every time.

It is also important to note that Google has NEVER  been hacked, however individual user accounts have been compromised lots of times because people have used poor passwords or have inadvertently revealed them.  Google users are being targeted in this way because the Google System itself is secure.

Finally, Consider the use of a Secure Password Management Service like Last Pass, so long as you use it in combination with a strong master password and two-factor authentication the last pass is a good way to remember all of your passwords and security credentials.

In the first in a series of Blog Posts about email security and deliverability,  I set out to explain what SPF is and why you should use it.

SPF stands for Sender Policy Framework and whilst that might sound very technical it’s actually a very simple validation system that was introduced to detect email spoofing.  SPF provides a mechanism which allows the receiving mail server to check if incoming mail claiming to be from a domain is coming from an email server authorised to send mail on behalf of that domain.

For example, my Mail Server receives an email claiming to be from your company, but the email was sent via BT internet email server.  My mail server checks your company’s publicly published SPF record and finds BT Internets mail server is not authorised to send mail on behalf of your company, therefore my Mail Server should either reject the message or treat it with suspicion.

Similarly, if my Mail Server receives an email claiming to be from your company and the email was sent via a Google for Work email server.  My mail server checks your company’s publicly published SPF record and finds Google’s SPF record is referenced in your company’s SPF record because you are a Google for Work Customer, then my Mail Server is going to treat your message as genuine and will continue to scan the message in the normal way and consider it more positively in the overall spam filtering process.

The list of authorised sending mail servers for a domain is published in the publicly accessible Domain Name System (DNS) records for your domain in the form of a specially formatted TXT record. For example Ramsay.IT SPF record is:

v=spf1 a include:_spf.google.com include:autotask.net include:spf1.mcsv.net include:_spf.freeagent.com include:spf.mandrillapp.com -all

You can find out more about how to create and manage your SPF records here: http://www.openspf.org/

Essentially the receiving mail server checks the identity of the server sending it mail against the SPF record and returns one of the following results:

  • Pass, The SPF record designates the sending mail server is allowed to send mail => Accept the message
  • Fail, The SPF record has designated the sending mail server as NOT being allowed to send =>Reject the message
  • SoftFail, The SPF record has designated the sending mail server as NOT being allowed to send but is in transition => Accept the message but mark as Spam
  • Neutral, The SPF record specifies explicitly that nothing can be said about validity => Accept the message
  • None, The domain does not have an SPF record =>  Accept the message

Why use SPF?

Email spam and phishing emails very often contain forged “from” addresses.  By publishing and checking SPF records you help to ensure that these forged emails are not delivered and that they do not harm the reputation of your domain.  If a user is receiving spam which claims to be from your domain and they report it via some spam systems this will count against your domain’s reputation. Your Domain’s reputation with a number of spam filtering systems will, of course, affect the chances of your genuine email being considered spam.

By including an SPF record you also allow the receiving mail system to verify that the mail is genuine thus increasing the odds that the email will pass that recipient’s spam filtering system.  This is what we call “Increased Deliverability”.

If you are a Welgo Customer or a Welgo Google for Work Customer we will have created an SPF record for you. If you have any questions about that record please just call Welgo  helpline on 0131 667 0195 or raise a support request via the Welgo Support Portal

If you are not already a Welgo Customer please call us and one of the team will be happy arrange an appointment to discuss how Welgo can help you with your Business IT needs.

In the second in a series of Blog Posts about email security and deliverability,  I set out to explain what DKIM is and why you should use it.

DKIM or Domain Keys Identified Mail signature is an email authentication method, which allows your outgoing mail server to sign outgoing mail thus providing the receiving mail server with a mechanism to check that incoming mail from a domain is genuine.  DKIM allows the receiver to check that an email claiming to come from a specific domain was indeed authorised by that domains administrator. This is achieved by the use of Public-Private key cryptographic authentication and whilst that might sound very technical it’s actually a rather simple validation system that was introduced to help detect email spoofing and provide authentication of email.  

DKIM uses Public Key Digital Signature Encryption: this is a pair of numbers and a one way mathematical formula allows you to encrypt a message which anyone can decrypt with your public key, if the message does not decrypt successfully with your public key, it did not come from you because only you (hopefully) have access to your private key.  It is not normally possible to calculate your private key from your public key without a vast amount of data and very very large supercomputers.

Here’s how it works;  

You publish a public key in the publicly accessible Domain Name System (DNS) records for your domain in the form of a specially formatted TXT record. If you have more than one mail server or system you would publish one record for each email system.

When you send an email the mail system adds an encrypted header to the message, a string of text is created using your private encryption key and is not displayed to the recipient (see Email headers).  

The receiving mail server seeing the encrypted signature in the mail header looks in the DNS records for your public key.  It then checks the encrypted signature and verifies the authenticity of the message. Or otherwise treats the message accordingly for spam filtering.

One of the key limitations of DKIM is that if no encrypted signature is present in the mail headers, the receiving system will not check for a DKIM record in the sending domain’s DNS records.  Thus DKIM helps to ensure genuine mail is delivered but has little effect at preventing spoofing or spam mail from also being delivered. For that effect, we have to turn to DMARC records.

However by using DKIM, you allow the receiving mail system to verify that the mail is genuine thus increasing the odds that the email will pass that recipient’s spam filtering system.  This is what we call “Increased Deliverability”.

If you are a Welgo Customer or a Welgo Google for Work Customer we will have created a DKIM record for your Primary Email system, however, any third party systems you use to send email such as an email marketing system should also have its own DKIM record added. If you have any questions about these records or email security in general, please just call Welgo  helpline on 0131 667 0195 or raise a support request via the Welgo Support Portal.

If you are not already a Welgo Customer please call us and one of the team will be happy arrange an appointment to discuss how Welgo can help you with your Business IT needs.

DMARC Explained

In the third in a series of Blog Posts about email security and deliverability,  I set out to explain what DMARC is and why you should use it.

DMARC or Domain-based Message Authentication, Reporting and Conformance Policy is the most recent addition to a suite of email authentication methods available to companies.

A DMARC policy allows a domain to inform a receiving mail server that their emails should be protected by SPF and DKIM.  The DMARC Policy then informs the receiver what action should be taken if either of those authentication methods passes or fails.  DMARC also provides a mechanism for a domain to request feedback about a sender’s domain and messages that have failed the DMARC evaluation, this allows for fault finding and further strengthens the system.

DMARC is designed to help email receivers determine if the incoming message aligns with the guidance issued by the sender. If not, DMARC includes guidance on how to handle messages that fail the sender’s domain policy. DMARC doesn’t directly advise a recipient whether or not an email is spam or otherwise fraudulent.  Instead, DMARC requires that a message pass DKIM and SPF validation. This additional record ensures that a recipient knows which verification records to check for, the message must pass the SPF check and the domain in the From: header must match the domain used to validate SPF (must exactly match if strict alignment is specified).  For DKIM, the message must be validly signed and the domain of the valid signature must align with the domain in the From: field (again must exactly match for strict alignment). Under DMARC a message can fail even if it passes SPF or DKIM but fails the alignment test, ie if it was sent from test.welgo.co.uk but the alignment specified is strict.

DMARC policies are published in the publicly accessible Domain Name System (DNS) records for your domain in the form of a specially formatted TXT record. If you have more than one mail server or system you would publish one record for each email system.

The receiver sends daily aggregated reports to an email address specified by the sender domain indicating to the sender domain administrator how many emails have been received and if these emails passed SPF and/or DKIM and were aligned or not.  This allows the Sender domain administrator to assess the impact and effectiveness of the DKIM record during the deployment phase.

During the deployment phase there are a number of options which limit any negative effect such as, false positives specifying that messages should be quarantined opposed to rejected and setting the percentage of messages subjected to filtering.

By using DMARC with SPF and DKIM you allow the receiving mail system to verify that the mail is genuine thus increasing the odds that the email will pass that recipient’s spam filtering system.  This is what we call “Increased Deliverability”. You also help to protect the reputation of your domain and decrease the chances of your domain being used in SPAM and Phishing attacks.

How does DMARC Work in practice?  

Hopefully, this graphic from https://dmarc.org/overview/ explains a little more clearly.

DMARC Explained


DMARC Explained


If you are a Welgo Customer or a Welgo Google for Work Customer we will create a DMARC record for you.  However we do not always do this as standard, this is because any third party systems you use to send email such as an email marketing system must be set up with your SPF and DKIM records before we can enable DMARC.  Failing to do so would prevent emails from those systems reaching there intended recipients. If you have any questions about these records, would like DMARC Enabled or email security in general, please just call Welgo helpline on 0131 667 0195 or raise a support request via the Welgo Support Portal.

If you are not already a Welgo Customer please call us and one of the team will be happy arrange an appointment to discuss how Welgo can help you with your Business IT needs.